From oliver.weinmann at me.com Sun Nov 1 07:55:53 2020 From: oliver.weinmann at me.com (Oliver Weinmann) Date: Sun, 1 Nov 2020 08:55:53 +0100 Subject: Which deployment method for ceph (rook|ceph-ansible|tripleo) Message-ID: <16c93e9a-765e-f254-a915-8e92fb6a7dcb@me.com> Hi, I'm still in the process of preparing a OpenStack POC. I'm 100% sure that I want to use CEPH and so I purchased the book Mastering CEPH 2nd edition. First of all, It's a really good book. It basically explains the various methods how ceph can be deployed and also the components that CEPH is build of. So I played around a lot with ceph-ansible and rook in my virtualbox environment. I also started to play with tripleo ceph deployment, although I haven't had the time yet to sucessfully deploy a openstack cluster with CEPH. Now I'm wondering, which of these 3 methods should I use? rook ceph-ansible tripleo I also want to use CEPH for NFS and CIFS (Samba) as we have plenty of VMs running under vSphere that currently consume storage from a ZFS storage via CIFS and NFS. I don't know if rook can be used for this. I have the feeling that it is purely meant to be used for kubernetes? And If I would like to have CIFS and NFS maybe tripleo is not capable of enabling these features in CEPH? So I would be left with ceph-ansible? Any suggestions are very welcome. Best Regards, Oliver From jerome.pansanel at iphc.cnrs.fr Sun Nov 1 08:49:09 2020 From: jerome.pansanel at iphc.cnrs.fr (Jerome Pansanel) Date: Sun, 1 Nov 2020 09:49:09 +0100 Subject: Which deployment method for ceph (rook|ceph-ansible|tripleo) In-Reply-To: <16c93e9a-765e-f254-a915-8e92fb6a7dcb@me.com> References: <16c93e9a-765e-f254-a915-8e92fb6a7dcb@me.com> Message-ID: Hi Oliver, Due to recent changes in CEPH Nautilus and Octopus (new Orchestrator APIs), we decided to switch to Rook. It is still in an experimental stage on our platform, but it seems promising. Cheers, Jerome Le 01/11/2020 à 08:55, Oliver Weinmann a écrit : > Hi, > > I'm still in the process of preparing a OpenStack POC. I'm 100% sure > that I want to use CEPH and so I purchased the book Mastering CEPH 2nd > edition. First of all, It's a really good book. It basically explains > the various methods how ceph can be deployed and also the components > that CEPH is build of. So I played around a lot with ceph-ansible and > rook in my virtualbox environment. I also started to play with tripleo > ceph deployment, although I haven't had the time yet to sucessfully > deploy a openstack cluster with CEPH. Now I'm wondering, which of these > 3 methods should I use? > > rook > > ceph-ansible > > tripleo > > I also want to use CEPH for NFS and CIFS (Samba) as we have plenty of > VMs running under vSphere that currently consume storage from a ZFS > storage via CIFS and NFS. I don't know if rook can be used for this. I > have the feeling that it is purely meant to be used for kubernetes? And > If I would like to have CIFS and NFS maybe tripleo is not capable of > enabling these features in CEPH? So I would be left with ceph-ansible? > > Any suggestions are very welcome. > > Best Regards, > > Oliver > > -- Jerome Pansanel, PhD Technical Director at France Grilles Head of Scientific Cloud Infrastructure (SCIGNE) at IPHC IPHC || GSM: +33 (0)6 25 19 24 43 23 rue du Loess, BP 28 || Tel: +33 (0)3 88 10 66 24 F-67037 STRASBOURG Cedex 2 || Fax: +33 (0)3 88 10 62 34 From florian at datalounges.com Sun Nov 1 09:19:45 2020 From: florian at datalounges.com (Florian Rommel) Date: Sun, 1 Nov 2020 11:19:45 +0200 Subject: Weird iptables problem Message-ID: <39FFD224-4615-4DBE-A169-711ECA78EB17@datalounges.com> Hi, so we deployed a test cluster with 8 total nodes. Openstack ussuri, Ubuntu 20.04 , opevswitch, octavia. Everything works more or less as it should , however when deploying a loadbalancer (which works perfectly), instances on the same node as the amphora deployment loose all access via public up after open switch logs a message : modified security group “long uuid”, which is a sec group belonging to octavia. What effect does that have with the rest? Questions: Should ufw be on and started? How can we troubleshoot this more in depth? Why does the lb work perfectly whole instance with floating up loos all access from the internet but the lb works fine passing thru the web services. One more thing. Does anyone have a recommended sysctl.conf Settings list for Ubuntu/ openstack ussuri? Thanks already and have a nice weekend, //f From oliver.weinmann at me.com Sun Nov 1 09:28:48 2020 From: oliver.weinmann at me.com (Oliver Weinmann) Date: Sun, 1 Nov 2020 10:28:48 +0100 Subject: Which deployment method for ceph (rook|ceph-ansible|tripleo) In-Reply-To: References: <16c93e9a-765e-f254-a915-8e92fb6a7dcb@me.com> Message-ID: Hi Jerome, thanks for your reply. Ok, but can rook also be used outside of kubernetes? Can I provision e.g. volumes for openstack cinder? Am 01.11.2020 um 09:49 schrieb Jerome Pansanel: > Hi Oliver, > > Due to recent changes in CEPH Nautilus and Octopus (new Orchestrator > APIs), we decided to switch to Rook. It is still in an experimental > stage on our platform, but it seems promising. > > Cheers, > > Jerome > > Le 01/11/2020 à 08:55, Oliver Weinmann a écrit : >> Hi, >> >> I'm still in the process of preparing a OpenStack POC. I'm 100% sure >> that I want to use CEPH and so I purchased the book Mastering CEPH 2nd >> edition. First of all, It's a really good book. It basically explains >> the various methods how ceph can be deployed and also the components >> that CEPH is build of. So I played around a lot with ceph-ansible and >> rook in my virtualbox environment. I also started to play with tripleo >> ceph deployment, although I haven't had the time yet to sucessfully >> deploy a openstack cluster with CEPH. Now I'm wondering, which of these >> 3 methods should I use? >> >> rook >> >> ceph-ansible >> >> tripleo >> >> I also want to use CEPH for NFS and CIFS (Samba) as we have plenty of >> VMs running under vSphere that currently consume storage from a ZFS >> storage via CIFS and NFS. I don't know if rook can be used for this. I >> have the feeling that it is purely meant to be used for kubernetes? And >> If I would like to have CIFS and NFS maybe tripleo is not capable of >> enabling these features in CEPH? So I would be left with ceph-ansible? >> >> Any suggestions are very welcome. >> >> Best Regards, >> >> Oliver >> >> > From johfulto at redhat.com Sun Nov 1 18:34:06 2020 From: johfulto at redhat.com (John Fulton) Date: Sun, 1 Nov 2020 13:34:06 -0500 Subject: Which deployment method for ceph (rook|ceph-ansible|tripleo) In-Reply-To: References: <16c93e9a-765e-f254-a915-8e92fb6a7dcb@me.com> Message-ID: On Sun, Nov 1, 2020 at 4:32 AM Oliver Weinmann wrote: > > Hi Jerome, > > thanks for your reply. Ok, but can rook also be used outside of > kubernetes? Can I provision e.g. volumes for openstack cinder? Rook provides storage for k8s and Ceph is one of its storage providers. I don't think a Ceph cluster as orchestrated by rook was designed for access outside of k8s. I've seen people expose parts of it outside of k8s [0] but that type of thing doesn't seem to be a standard rook pattern. I wonder how many people are doing that. If you want Ceph to provide pools to both k8s and OpenStack, then one approach I see is the following: 1. Install Ceph on its own independent system so it's external to both OpenStack and k8s and use cephadm to do that deployment [1] 2. Install rook for k8s access to Ceph but direct rook to the external Ceph cluster from step 1 [2] 3. Install OpenStack but direct it to the external Ceph cluster from step 1, e.g. TripleO can do this [3] I'm suggesting a tool to install Ceph, cephadm [1], which isn't in the current list of tools in the subject. One benefit of this tool is that you'd have the new Orchestrator APIs that Jerome mentioned but you wouldn't have to use k8s if you don't want to. The downside is that you don't have k8s operators directly managing Ceph. An upside of using the 3-step approach above is that one Ceph cluster can be used as the same backend to both OpenStack and k8s services. I haven't done this myself but I don't see why this wouldn't work. You'd just manage different pools/cephx keys for different services. If you're not planning to use k8s, the above (without step 2) would also work well for a large deployment. If you're interested in a smaller footprint with just OpenStack and Ceph, perhaps where you collocate OSD and Compute containers (aka "hyperconverged"), then TripleO will deploy that too and it uses ceph-ansible to deploy Ceph behind the scenes [4]. TripleO can also deploy CephFS for NFS access from OpenStack tenants via ganesha. This can work even if the Ceph cluster itself is external [6] though access to the NFS service is meant for OpenStack tenants, not e.g. VMWare tenants. This method of deployment will likely evolve over the next two TripleO cycles to use cephadm in place of ceph-ansible [7]. John [0] https://www.adaltas.com/en/2020/04/16/expose-ceph-from-rook-kubernetes/ [1] https://docs.ceph.com/en/latest/cephadm [2] https://github.com/rook/rook/blob/master/design/ceph/ceph-external-cluster.md [3] https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/ceph_external.html [4] https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/ceph_config.html [5] https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/deploy_manila.html [6] https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/deploy_manila.html#deploying-the-overcloud-with-an-external-backend [7] https://review.opendev.org/#/c/723108/ > > Am 01.11.2020 um 09:49 schrieb Jerome Pansanel: > > Hi Oliver, > > > > Due to recent changes in CEPH Nautilus and Octopus (new Orchestrator > > APIs), we decided to switch to Rook. It is still in an experimental > > stage on our platform, but it seems promising. > > > > Cheers, > > > > Jerome > > > > Le 01/11/2020 à 08:55, Oliver Weinmann a écrit : > >> Hi, > >> > >> I'm still in the process of preparing a OpenStack POC. I'm 100% sure > >> that I want to use CEPH and so I purchased the book Mastering CEPH 2nd > >> edition. First of all, It's a really good book. It basically explains > >> the various methods how ceph can be deployed and also the components > >> that CEPH is build of. So I played around a lot with ceph-ansible and > >> rook in my virtualbox environment. I also started to play with tripleo > >> ceph deployment, although I haven't had the time yet to sucessfully > >> deploy a openstack cluster with CEPH. Now I'm wondering, which of these > >> 3 methods should I use? > >> > >> rook > >> > >> ceph-ansible > >> > >> tripleo > >> > >> I also want to use CEPH for NFS and CIFS (Samba) as we have plenty of > >> VMs running under vSphere that currently consume storage from a ZFS > >> storage via CIFS and NFS. I don't know if rook can be used for this. I > >> have the feeling that it is purely meant to be used for kubernetes? And > >> If I would like to have CIFS and NFS maybe tripleo is not capable of > >> enabling these features in CEPH? So I would be left with ceph-ansible? > >> > >> Any suggestions are very welcome. > >> > >> Best Regards, > >> > >> Oliver > >> > >> > > > From andy at andybotting.com Sun Nov 1 23:11:30 2020 From: andy at andybotting.com (Andy Botting) Date: Mon, 2 Nov 2020 10:11:30 +1100 Subject: [MURANO] DevStack Murano "yaql_function" Error In-Reply-To: References: Message-ID: Hi Rong and İzzetti, I haven't solved the issue yet, but if I do, I'll push up a review. > I had some time to track down the error AttributeError: 'method' object has no attribute '__yaql_function__' which turned out to be a Python 3 issue and I've got a review up here for it https://review.opendev.org/#/c/760470/ I've fixed a couple of Python 3 specific issues recently, so I'd recommend you either use the Train version with Python 2 or if you want to run on Python 3 then you'll need to use master right now with my patches on top. cheers, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangerzonen at gmail.com Mon Nov 2 02:03:22 2020 From: dangerzonen at gmail.com (dangerzone ar) Date: Mon, 2 Nov 2020 10:03:22 +0800 Subject: How to config DPDK compute in OVN Message-ID: Hi....as far I understand ovs does support dpdk compute to be deployed. I'm referring to the guideline ' *https://docs.openstack.org/networking-ovn/queens/admin/dpdk.html * ' ... It's too brief.. May I know how to config dpdk compute in OVN networking openstack? Hope someone could help what is the config to be done.... Currently compute is run without dpdk over openstack train ovn based. Please need some info on how I can proceed. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From akekane at redhat.com Mon Nov 2 05:36:31 2020 From: akekane at redhat.com (Abhishek Kekane) Date: Mon, 2 Nov 2020 11:06:31 +0530 Subject: [Glance] Wallaby PTG summary Message-ID: Hi All, We had our second virtual PTG last week from 26th October to 30th October 2020. Thanks to everyone who joined the virtual PTG sessions. Using bluejeans app we had lots of discussion around different topics for glance, glance + cinder and glance + tempest. I have created etherpad [1] with Notes from session and which also includes the recordings of each discussion. The same etherpad includes milestone wise priorities at the bottom. Below topics we discussed during PTG: 1. Victoria retrospection 2. Image encryption (progress) 3. Remove single store configuration from glance_store 4. Cache-API 5. Duplicate downloads 6. Extend issue when using nfs cinder backend (with cinder team) 7. Multi-format images 8. Cluster awareness 9. Improve performance of ceph/rbd store of glance (multi-threaded rbd driver) 10. Task API's for general users 11. Tempest enhancement/bridge gap between glance and tempest 12. Code cleanup, enhancements 13. Wallaby priorities Kindly let me know if you have any questions about the same. [1] https://etherpad.opendev.org/p/glance-wallaby-ptg Thank you, Abhishek -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafaelweingartner at gmail.com Mon Nov 2 11:43:30 2020 From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=) Date: Mon, 2 Nov 2020 08:43:30 -0300 Subject: [Cloudkitty][ptg] CloudKitty Wallaby PTG outcome Message-ID: Hey people, Thanks to everyone who attended the CloudKitty PTG sessions, we covered a lot during the meeting. The Etherpad is available at [1]. In Etherpad [1], I added the notation "TODO(XXX):" in the topics we discussed, that require effort from someone. The work can be either writing a use case story, developing extensions/features, or creating test cases. Therefore, if you are interested in working with that item, do not hesitate and put your name there. Anyone in the community is welcome. [1] https://etherpad.opendev.org/p/cloudkitty-ptg-wallaby -- Rafael Weingärtner -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesse at odyssey4.me Mon Nov 2 11:55:35 2020 From: jesse at odyssey4.me (Jesse Pretorius) Date: Mon, 2 Nov 2020 11:55:35 +0000 Subject: [tripleo] please avoid creating ansible playbooks that call modules for trivial tasks In-Reply-To: References: <0bea7456-e413-1f05-ce91-8b1738c8777b@redhat.com> Message-ID: On Thu, 2020-10-29 at 07:00 -0600, Alex Schultz wrote: On Thu, Oct 29, 2020 at 5:32 AM Bogdan Dobrelya < bdobreli at redhat.com > wrote: In today TripleO client development we invoke ansible playbooks instead of Mistral workflows. I believe this may only be justified for non-trivial things. Otherwise please just import python modules into the client command actions without introducing additional moving parts in the form of ansible modules (that import the same python modules as well). I see no point of adding a new playbook and a new module for that trivial example. Those 4 packages could (and should) be as well installed from the client caller code without any ansible involved in the middle IMO. While I can agree to a certain extent, there's actually some good reasons to even move trivial bits into ansible. Personally I'm not certain the switch to using ansible under the covers from some cli actions is an improvement (questionable logging, error handling isn't great), there is a case for certain actions. As we discussed at the PTG, the overcloud image building process is one of those things that actually has to be executed on bare metal. If we wanted to continue to look at containerizing the cli, we need to be able to invoke this action from within the container but build on an external host. This is something that is trivial with the switch to an ansible playbook that isn't available when running under the pure python as it exists today. Container builds would be another example action that is required to run on a bare metal host. Additionally the movement of this invocation to an ansible module also allows the action to be moved into something like the undercloud installation as an optional action as part of the deployment itself. It's not exactly without merit in this case. I don't really care one way or another for this action, however I don't think it's as simple as saying "oh it's just a few lines of code so we shouldn't..." What it sounds like is that there's a need for documented guidelines. A lot of changes have been made as part of a learning process and we now know a lot more about what tasks are better suited to be done directly in the client vs via ansible roles vs via ansible modules. If we can document these best practises then we can guide any new changes according to them. It seems to me that we need to consider: 1. Requirements - what needs to get done 2. Constraints - does the action need something special like access to devices or kernel API's 3. Testability - something in python or an ansible module is unit testable, whereas an ansible role is more difficult to properly test 4. Scalability - complex ansible tasks/vars scale far worse that ansible modules 5. Maintainability - many factors are involved here, but sometimes efficiency should be sacrificed for simplicity -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangerzonen at gmail.com Mon Nov 2 12:04:47 2020 From: dangerzonen at gmail.com (dangerzone ar) Date: Mon, 2 Nov 2020 20:04:47 +0800 Subject: [undercloud][train]Fatal error during train undercloud deployment Message-ID: Hi all, I keep getting the same fatal error below during undercloud deployment. My environment is VMware VM Centos7 undercloud (openstack train) and refers to the official openstack guideline. TASK [tripleo_container_manage : Print failing containers] ********************* Monday 02 November 2020 19:55:07 +0800 (0:00:00.182) 0:17:50.677 ******* fatal: [undercloud]: FAILED! => changed=false msg: 'Container(s) with bad ExitCode: [u''container-puppet-ironic'', u''container-puppet-zaqar''], check logs in /var/log/containers/stdouts/' I even tried with clean different VM and all give me same error. Appreciate some help please. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From noonedeadpunk at ya.ru Mon Nov 2 12:18:49 2020 From: noonedeadpunk at ya.ru (Dmitriy Rabotyagov) Date: Mon, 02 Nov 2020 14:18:49 +0200 Subject: [openstack-ansible] Wallaby PTG results Message-ID: <2577631604317234@mail.yandex.ru> Hi, Bellow you may find summarization of descisions that were taken during PTG discussion. Victoria retrospective ---------------------------- 1. We're pretty far from dropping resource creation code out of the tempest, as we should respect TripleO needs here. So leaving as is during this cycle but adding option to be possible to omit resource creation. 2. We decided to postpone prometheus integration (as well as libvirtd exporter) as we don't have enough resource to implement and moreover support it in the future. 3. Decided to leave ELK stack in ops repo as for now. 4. Adjusting bootstrap-ansible to pick up gerrit patches idea was also postponed as has super low prio and we have a lot of more useful things on our hands 5. We didn't have much progress in tempest coverage of existing roles, we should proceed with it during W. Same is applicable to the roles overall speedup topic. Descisions taken for Wallaby -------------------------------------- 1. Remove nspawn from docs, and set it to unmaintained state in V. Remove code in W. 2. Document how upgrade paths for distro installs are difficult, and may/may not align with OSA releases 3. Check through the logs what roles are we covering with tempest, and what not 4. extract deprecation messages from journal files to the separate log 5. Continue working on speeding up OSA runtime: - Fight with skipped tasks (ie by moving them to separate files that would be included) - most valid for systemd service, systemd_networkd and python_venv_build roles - Try to split up variables by group_vars - Try to use include instead of imports again 6. Set TRANSFORM_INVALID_GROUP_CHARS to ignore in V and replace invalid chars in groups later. For octavia we can temporary add 2 groups (old style and new style) for migration process. 7. Try to speedup zuul required projects clone process and talk to zuul folks 8. Finally do Integrated repo deploy for Zun and sync deployment process with service docs 9. Installation of ara for deployer needs - ARA deploy on localhost, configured by variables - Option for remote ARA - Option for UI server locally 10. Create Root CA on deploy host and overall SSL approach refactoring. Futher discussion in SPEC: https://review.opendev.org/#/c/758805/ Original etherpad for the reference https://etherpad.opendev.org/p/osa-certificates-refactor 11. For ansible 2.11 (which requires py3.8 on deploy host) we can use pyenv for ansible venv to workaround this, and leave hosts themselves on their native python 12. Move neutron-server to standalone group in env.d 13. Add Senlin tempest test - Add plugins (source only) to os_tempest https://review.opendev.org/754044 - Upstream senlin endpoints fix https://review.opendev.org/74987 - Enable senlin tempest plugin in integrated repo https://review.opendev.org/#/c/754105/ - Test patch for senlin/tempest https://review.opendev.org/754045 14 Document in os_nova defaults way to manage ratios via api (ie set cpu_allocation_ratio to 0.0) (regarding https://review.opendev.org/#/c/758029/) 15. Add support for zookeeper deployment for services coordination (low priority) 16. Check where we don't use uwsgi role and see if we can use it there now (like designate, neutron-api) (low priority) -- Kind Regards, Dmitriy Rabotyagov From Aija.Jaunteva at dell.com Mon Nov 2 12:30:25 2020 From: Aija.Jaunteva at dell.com (Jaunteva, Aija) Date: Mon, 2 Nov 2020 12:30:25 +0000 Subject: [ironic] Configuration mold follow-up Message-ID: Hi, to follow up on Ironic PTG session about Configuration molds [1] I'm scheduling a call to discuss remaining items (mainly storage of the molds). Anyone interested please add your availability in Doodle [2]. When time slot decided, will share call details. Regards, Aija [1] https://etherpad.opendev.org/p/ironic-wallaby-ptg line 216 [2] https://doodle.com/poll/dry4x5tbmhi6x6p3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at est.tech Mon Nov 2 13:07:15 2020 From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer) Date: Mon, 02 Nov 2020 14:07:15 +0100 Subject: [nova] python3.9 support Message-ID: <3476JQ.0LX9S5E3FLUD2@est.tech> Hi, I run unit and functional tests (where applicable) for nova, python-novaclient, os-vif, placement, osc-placement, os-traits, os-resource-classes with python 3.9 and everything is green. I've proposed some tox.ini targets where it was needed [1][2][3] Cheers, gibi [1]https://review.opendev.org/#/c/760884/ [2]https://review.opendev.org/#/c/760890/ [3]https://review.opendev.org/#/c/760912/ From aschultz at redhat.com Mon Nov 2 14:16:54 2020 From: aschultz at redhat.com (Alex Schultz) Date: Mon, 2 Nov 2020 07:16:54 -0700 Subject: [undercloud][train]Fatal error during train undercloud deployment In-Reply-To: References: Message-ID: On Mon, Nov 2, 2020 at 5:11 AM dangerzone ar wrote: > > Hi all, I keep getting the same fatal error below during undercloud deployment. My environment is VMware VM Centos7 undercloud (openstack train) and refers to the official openstack guideline. > > TASK [tripleo_container_manage : Print failing containers] ********************* > Monday 02 November 2020 19:55:07 +0800 (0:00:00.182) 0:17:50.677 ******* > fatal: [undercloud]: FAILED! => changed=false > msg: 'Container(s) with bad ExitCode: [u''container-puppet-ironic'', u''container-puppet-zaqar''], check logs in /var/log/containers/stdouts/' > > I even tried with clean different VM and all give me same error. Appreciate some help please. Thank you. Check containers, they are likely centos8 based containers which fail when trying to deploy on centos7. At this point it's highly recommended to use centos8 for train as it's readily available from RDO now. From ionut at fleio.com Mon Nov 2 14:23:19 2020 From: ionut at fleio.com (Ionut Biru) Date: Mon, 2 Nov 2020 16:23:19 +0200 Subject: [magnum] hyperkube deprecation situation In-Reply-To: <601fe2f9-52fb-c55f-12c7-8da36c2d9484@catalyst.net.nz> References: <601fe2f9-52fb-c55f-12c7-8da36c2d9484@catalyst.net.nz> Message-ID: Hi Feilong, Thanks for the reply. My issue is that currently there is no way I can overwrite hyperkube and use a 3rd party image because once I set up container_infra_prefix': ' docker.io/rancher/', magnum tries to use this registry for all images. On Sat, Oct 24, 2020 at 10:03 PM feilong wrote: > Hi Ionut, > > We have already made the decision actually, we would like to support both > binary and container for kubelet. Spyros has started the work with > https://review.opendev.org/#/c/748141/ and we will backport it to > Victoria. At this stage, if you need to use latest k8s version, the simple > way is building your own hyperkube image which is not difficult. You can > just copy the folder https://github.com/kubernetes/kubernetes/tree/v1.18.8/cluster/images/hyperkube > to the version you want to build images and follow the process. Or, you > can use the hyperkube image built by 3rd parties, e.g. rancher. Please let > me know if you need more information. > > > On 23/10/20 8:05 pm, Ionut Biru wrote: > > Hi guys, > > I was hoping that in Victoria there will be a decision regarding this > topic. > Currently, if I use vanilla magnum, I'm stuck on 1.18.6 being the latest > version, even so 1.18.10 was released. > > We are kinda stuck on a version that maybe in the near future is pruned to > security issues. > > How do other operators are using magnum (vanilla) and keeping their > kubernetes up to date? > > Are operators using a forked version of > https://review.opendev.org/#/c/752254/ ? > > > -- > Ionut Biru - https://fleio.com > > -- > Cheers & Best regards, > Feilong Wang (王飞龙) > ------------------------------------------------------ > Senior Cloud Software Engineer > Tel: +64-48032246 > Email: flwang at catalyst.net.nz > Catalyst IT Limited > Level 6, Catalyst House, 150 Willis Street, Wellington > ------------------------------------------------------ > > -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at est.tech Mon Nov 2 08:47:23 2020 From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer) Date: Mon, 02 Nov 2020 09:47:23 +0100 Subject: [nova] PTG Message-ID: Hi, Thank you all for the PTG participation! All our agreements and decisions are marked in the etherpad[1] with AGREED word. To avoid loosing this information I made a dump of the etherpad on Friday at the end of the PTG and attached to this mail Cheers, gibi [1] https://etherpad.opendev.org/p/nova-wallaby-ptg -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangerzonen at gmail.com Mon Nov 2 12:17:17 2020 From: dangerzonen at gmail.com (dangerzone ar) Date: Mon, 2 Nov 2020 20:17:17 +0800 Subject: [undercloud][train]Fatal error during train undercloud deployment In-Reply-To: References: Message-ID: I'm attaching a snippet of the problem for your reference. Thank you. On Mon, Nov 2, 2020 at 8:04 PM dangerzone ar wrote: > Hi all, I keep getting the same fatal error below during undercloud > deployment. My environment is VMware VM Centos7 undercloud (openstack > train) and refers to the official openstack guideline. > > TASK [tripleo_container_manage : Print failing containers] > ********************* > Monday 02 November 2020 19:55:07 +0800 (0:00:00.182) 0:17:50.677 > ******* > fatal: [undercloud]: FAILED! => changed=false > msg: 'Container(s) with bad ExitCode: [u''container-puppet-ironic'', > u''container-puppet-zaqar''], check logs in /var/log/containers/stdouts/' > > I even tried with clean different VM and all give me same error. > Appreciate some help please. Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: undercloud_error2.jpg Type: image/jpeg Size: 109223 bytes Desc: not available URL: From sean.mcginnis at gmx.com Mon Nov 2 14:53:44 2020 From: sean.mcginnis at gmx.com (Sean McGinnis) Date: Mon, 2 Nov 2020 08:53:44 -0600 Subject: [all] X Release Naming Message-ID: <20201102145344.GA1505236@sm-workstation> Hello everyone, This is to notify everyone that we are now kicking off the release naming process for the 'X' OpenStack release. Starting with the last W naming, we had altered our traditional way of choosing a release name to allow any name that meets the basic criteria - basically that the name begins with the chosen letter, it is made up if the ISO basic Latin alphabet, and that it is 10 characters or less in length. Community proposed names are collected on the wiki page for the X Release Naming. This page also includes more details about the process and timing: https://wiki.openstack.org/wiki/Release_Naming/X_Proposals We welcome any names from the community. This should be an intersting release to see what everyone comes up with! Please add any ideas to the wiki page. -- Sean McGinnis From fungi at yuggoth.org Mon Nov 2 15:10:46 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 2 Nov 2020 15:10:46 +0000 Subject: Python 3.9 is here in Debian Sid In-Reply-To: <20201016135910.paltyva5ut2x5qcc@yuggoth.org> References: <12e2eefa-21c5-4b2e-67a9-662e04bd38c7@debian.org> <4fd89e88-d8ce-7faa-772f-0908a3387d5c@goirand.fr> <20201016135910.paltyva5ut2x5qcc@yuggoth.org> Message-ID: <20201102151046.jgkwy5sek3n3rmqx@yuggoth.org> On 2020-10-16 13:59:10 +0000 (+0000), Jeremy Stanley wrote: > On 2020-10-16 10:21:34 +0200 (+0200), Thomas Goirand wrote: > [...] > > I also think it'd be nice to have non-voting jobs detecting > > deprecated stuff. For example, a quick grep shows that a lot of > > projects are still using collections.Mapping instead of > > collections.abc.Mapping (which is to be removed in Python 3.10, > > according to the 3.9 release notes). Would there be a way to get > > our CI report these issues earlier? > > They're going to all explode, at least until PBR gets some more > changes merged and released to stop doing deprecated things. I've > been slowly working my way through testing simple PBR-using projects > with PYTHONWARNINGS=error (instead of =default::DeprecationWarning) > and fixing or noting the issues I encounter. Up until recently, a > number of its dependencies were also throwing deprecation warnings > under 3.9, but now I think we're down to just a couple of remaining > fixes pending. We didn't want to try to rush in a new PBR release > until Victoria was wrapped up, but now I think we can finish this > fairly soon. Just to follow up, at this point I think we've merged and released everything PBR needs for this, but now it's become apparent we're blocked on Setuptools behavior. In particular, any call into setuptools/command/build_py.py unconditionally tries to import setuptools.lib2to3_ex.Mixin2to3 even if the build is not going to use lib2to3, so this will automatically raise a SetuptoolsDeprecationWarning if run with PYTHONWARNINGS=error. I expect we're stuck until https://github.com/pypa/setuptools/issues/2086 gets resolved, so this is the next thing to work on if anyone has time (it may take me a while to get around to submitting a PR as I expect they're going to want a very thorough cleanup). -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From zigo at debian.org Mon Nov 2 15:31:01 2020 From: zigo at debian.org (Thomas Goirand) Date: Mon, 2 Nov 2020 16:31:01 +0100 Subject: [nova] python3.9 support In-Reply-To: <3476JQ.0LX9S5E3FLUD2@est.tech> References: <3476JQ.0LX9S5E3FLUD2@est.tech> Message-ID: <460f346c-5b40-227d-c705-5de9a7dc92ee@debian.org> On 11/2/20 2:07 PM, Balázs Gibizer wrote: > Hi, > > I run unit and functional tests (where applicable) for nova, > python-novaclient, os-vif, placement, osc-placement, os-traits, > os-resource-classes with python 3.9 and everything is green. > > I've proposed some tox.ini targets where it was needed [1][2][3] > > Cheers, > gibi > > [1]https://review.opendev.org/#/c/760884/ > [2]https://review.opendev.org/#/c/760890/ > [3]https://review.opendev.org/#/c/760912/ Hi Gibi, Thanks for this work, it's very much appreciated here! Do you know if there anything patch that would need backporting to Victoria that I may have missed? (by this, I mean backported in the Debian packages, it doesn't have to be in the stable branch of upstream OpenStack) Cheers, Thomas Goirand (zigo) From elod.illes at est.tech Mon Nov 2 15:36:48 2020 From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=) Date: Mon, 2 Nov 2020 16:36:48 +0100 Subject: [ptl][release][stable][EM] Extended Maintenance - Stein In-Reply-To: References: Message-ID: <9445d2df-4dd2-1b2e-de50-84db3bd141bd@est.tech> Hi, Reminder: the planned date for Stein transition to Extended Maintenance is next Wednesday. If you have planned to do a final release, then it is a good time to do now. Warning: Do not merge and release risky patches in a hurry! Remember that Stein will be open for further patches, the only thing is that there won't be further official, upstream release anymore. Thanks, Előd On 2020. 10. 15. 10:55, Előd Illés wrote: > Hi, > > As Victoria was released yesterday and we are in a less busy period, it > is a good opportunity to call your attention to the following: > > In less than a month Stein is planned to enter into Extended > Maintenance phase [1] (planned date: 2020-11-11). > > I have generated the list of *open* and *unreleased* changes in > *stable/stein* for the follows-policy tagged repositories [2]. These > lists could help the teams, who are planning to do a *final* release on > Stein before moving stable/stein branches to Extended Maintenance. Feel > free to edit and extend these lists to track your progress! > > * At the transition date the Release Team will tag the *latest* (Stein) >   releases of repositories with *stein-em* tag. > * After the transition stable/stein will be still open for bugfixes, >   but there won't be any official releases. > > NOTE: teams, please focus on wrapping up your libraries first if there > is any concern about the changes, in order to avoid broken releases! > > Thanks, > > Előd > > [1] https://releases.openstack.org > [2] https://etherpad.openstack.org/p/stein-final-release-before-em > > > From bcafarel at redhat.com Mon Nov 2 16:16:31 2020 From: bcafarel at redhat.com (Bernard Cafarelli) Date: Mon, 2 Nov 2020 17:16:31 +0100 Subject: [neutron][stable]Proposing Rodolfo Alonso Hernandez as a stable branches core reviewer In-Reply-To: <1766330.tdWV9SEqCh@p1> References: <1766330.tdWV9SEqCh@p1> Message-ID: On Thu, 29 Oct 2020 at 12:33, Slawek Kaplonski wrote: > Hi, > > I would like to propose Rodolfo Alonso Hernandez (ralonsoh) to be new > member > of the Neutron stable core team. > Rodolfo works in Neutron since very long time. He is core reviewer in > master > branch already. > During last few cycles he also proved his ability to help with stable > branches. He is proposing many backports from master to our stable > branches as > well as doing reviews of other backports. > He has knowledge about stable branches policies. > I think that he will be great addition to our (not too big) stable core > team. > > I will open this nomination open for a week to get feedback about it. > A big +1 from me too, Rodolfo is quite active in stable branches, and reviews all stable specific steps (change backportability, cherrry-pick ID, conflict lines, proper backport chain, potential related backports, …) -- Bernard Cafarelli -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssbarnea at redhat.com Mon Nov 2 16:40:36 2020 From: ssbarnea at redhat.com (Sorin Sbarnea) Date: Mon, 2 Nov 2020 16:40:36 +0000 Subject: [tripleo] please avoid creating ansible playbooks that call modules for trivial tasks In-Reply-To: References: <0bea7456-e413-1f05-ce91-8b1738c8777b@redhat.com> Message-ID: <5D235976-DD12-438C-8A64-4C4EE57BBA01@redhat.com> IMHO, roles (inside collections) do provide quite good abstraction layer as they allow us to change implementation without changing the API (the variables passed to the role). If the role uses an embedded module, external one or lots of tasks to achieve the same functionality it is an implementation details. At any point in time we can refactor the role internals and create new modules, swap them, .... without messing its consumption. I cannot say the same about playbooks, especially those that call modules directly. If they call roles, we should be fine. > On 2 Nov 2020, at 11:55, Jesse Pretorius wrote: > > On Thu, 2020-10-29 at 07:00 -0600, Alex Schultz wrote: >> On Thu, Oct 29, 2020 at 5:32 AM Bogdan Dobrelya < >> bdobreli at redhat.com >> > wrote: >>> >>> In today TripleO client development we invoke ansible playbooks instead >>> of Mistral workflows. I believe this may only be justified for >>> non-trivial things. Otherwise please just import python modules into the >>> client command actions without introducing additional moving parts in >>> the form of ansible modules (that import the same python modules as well). >>> > >>> >>> I see no point of adding a new playbook and a new module for that >>> trivial example. Those 4 packages could (and should) be as well >>> installed from the client caller code without any ansible involved in >>> the middle IMO. >> >> While I can agree to a certain extent, there's actually some good >> reasons to even move trivial bits into ansible. Personally I'm not >> certain the switch to using ansible under the covers from some cli >> actions is an improvement (questionable logging, error handling isn't >> great), there is a case for certain actions. As we discussed at the >> PTG, the overcloud image building process is one of those things that >> actually has to be executed on bare metal. If we wanted to continue to >> look at containerizing the cli, we need to be able to invoke this >> action from within the container but build on an external host. This >> is something that is trivial with the switch to an ansible playbook >> that isn't available when running under the pure python as it exists >> today. Container builds would be another example action that is >> required to run on a bare metal host. Additionally the movement of >> this invocation to an ansible module also allows the action to be >> moved into something like the undercloud installation as an optional >> action as part of the deployment itself. It's not exactly without >> merit in this case. >> >> I don't really care one way or another for this action, however I >> don't think it's as simple as saying "oh it's just a few lines of code >> so we shouldn't..." > > What it sounds like is that there's a need for documented guidelines. A lot of changes have been made as part of a learning process and we now know a lot more about what tasks are better suited to be done directly in the client vs via ansible roles vs via ansible modules. If we can document these best practises then we can guide any new changes according to them. > > It seems to me that we need to consider: > > 1. Requirements - what needs to get done > 2. Constraints - does the action need something special like access to devices or kernel API's > 3. Testability - something in python or an ansible module is unit testable, whereas an ansible role is more difficult to properly test > 4. Scalability - complex ansible tasks/vars scale far worse that ansible modules > 5. Maintainability - many factors are involved here, but sometimes efficiency should be sacrificed for simplicity > From marios at redhat.com Mon Nov 2 17:13:30 2020 From: marios at redhat.com (Marios Andreou) Date: Mon, 2 Nov 2020 19:13:30 +0200 Subject: [tripleo] stable/victoria for tripleo repos In-Reply-To: References: Message-ID: o/ tripleos update on stable/victoria for the tripleo things. You may have noticed that we have a stable/victoria branch in our repos after [1] merged. The ci squad discussed this again today and we think we are good to go on merging to stable/victoria. I see there are already a few patches posted - note that we need to merge all of the .gitreview patches [2] and each repo has one, before patches will appear on stable/victoria in gerrit (or rebase your stuff onto the relevant review). For CI there is still some ongoing work - for example victoria upgrade jobs [3] - as well as third party/ovb branchful jobs. You can see some tests at [4][5]. Please shout if you see something wrong with the stable/victoria check or gate jobs - as usual or is your first port of call in freenode #tripleo #oooq. The wallaby series is also now a thing in launchpad - as usual we have wallaby-1 wallaby-2 wallaby-3 and wallaby-rc1 [6] - I used [7] as reference for the milestone dates. The victoria series is marked "current stable release" so wallaby is now the active series. I'll run the scripts tomorrow (once I find them ;)) to move all the bugs currently targeted to victoria into wallaby-1. please reach out for any clarifications/questions/suggestions/corrections! regards, marios [1] https://review.opendev.org/#/c/760571/ [2] https://review.opendev.org/#/c/760598/ [3] https://review.opendev.org/760323 [4] https://review.opendev.org/#/c/760359/ [5] https://review.opendev.org/#/c/760360/ [6] https://launchpad.net/tripleo/wallaby [7] https://releases.openstack.org/wallaby/schedule.html On Wed, Oct 28, 2020 at 1:57 PM Marios Andreou wrote: > > o/ > > So https://review.opendev.org/#/c/759449/ merged and we have > stable/victoria for > https://github.com/openstack/python-tripleoclient/tree/stable/victoria > and https://github.com/openstack/tripleo-common/tree/stable/victoria. We > have tests running e.g. https://review.opendev.org/#/c/760106/ . > > REMINDER PLEASE AVOID MERGING to stable/victoria tripleoclient/common for > now until > we are confident that our jobs are doing the right thing! > > Per the plan outlined in the message I'm replying to, please let's avoid > merging anything to client/common victoria until we have branched > stable/victoria for all the repos (implying we are happy with ci). > > Thanks in advance for your patience - without adequate ci coverage it will > be very easy to unintentionally break another part of the code and there > are many parts in tripleo ;) > > > On Fri, Oct 23, 2020 at 6:44 PM Marios Andreou wrote: > >> Hello all, >> >> I got some pings about tripleo stable/victoria so here is an update. >> >> The tripleo-ci team is busy preparing and we are almost ready. Basically >> we've blocked branching until we have adequate CI coverage. This means >> check & gate jobs but also promotion jobs so that check & gate aren't >> running with stale content. >> >> tl;dr We are aiming to branch victoria tripleoclient & common today and >> everything else next week - with more details below but please note: >> >> PLEASE AVOID MERGING to the stable/victoria tripleoclient/common that >> will appear after [4] until we are confident that our ci coverage is >> working well. >> >> Status: >> >> Most of our 'core' (standalone/scenarios/undercloud etc) check/gate jobs >> match on branch like [1] so we expect those to run OK once there is a >> stable/victoria available. There is ongoing work for branchful, upgrade, >> 3rd party and ovb jobs but we will not block branching on those. >> >> The victoria integration pipeline [2] (which produces current-tripleo) is >> in good shape. It was blocked on a nit in the component pipeline but it is >> resolved with [3]. Once we have a victoria promotion then we should be all >> clear to branch stable/victoria. >> >> Actions: >> >> A). today: make stable/victoria for python-tripleoclient & >> tripleo-common. The change at [4] will do this once merged. We will use >> this to see our check/gate jobs run against victoria & fix issues. >> >> B). next week: once we are happy with A). AND we've had a promotion, we >> release and make stable/victoria for everything else. >> >> Hopefully B). will happen end of next week but that depends on how well >> the above goes (plus inevitable delays cos PTG), >> >> I'll repeat this cos it's important: >> >> PLEASE AVOID MERGING to stable/victoria tripleoclient/common for now >> until we are confident that our jobs are doing the right thing! >> >> As always grateful for a sanity check or any thoughts about any of the >> above - I'm pretty new to this (weshay has been a great help so far thank >> you weshay++), >> >> thanks, >> >> marios >> >> [1] >> https://opendev.org/openstack/tripleo-ci/src/commit/d5514028452f9d427949f5a8fac26b48bd0d7c03/zuul.d/standalone-jobs.yaml#L795 >> [2] >> https://review.rdoproject.org/zuul/builds?pipeline=openstack-periodic-integration-stable1 >> [3] https://review.rdoproject.org/r/#/c/30654/ >> [4] https://review.opendev.org/#/c/759449/ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From melwittt at gmail.com Mon Nov 2 17:36:19 2020 From: melwittt at gmail.com (melanie witt) Date: Mon, 2 Nov 2020 09:36:19 -0800 Subject: [keystone][policy] user read-only role not working In-Reply-To: <17587cfe3a2.c5a6e78920408.1786542316064610506@zohocorp.com> References: <174c3a06897.bdfa9ca56831.6510718612076837121@zohocorp.com> <2b1b796a-9136-3066-0d1b-553a41065ca5@gmail.com> <17587cfe3a2.c5a6e78920408.1786542316064610506@zohocorp.com> Message-ID: <7a1ca866-318b-8d95-036b-5329b4207a2b@gmail.com> Adding back the mailing list +openstack-discuss@ On 11/1/20 23:15, its-openstack at zohocorp.com wrote: > Dear Openstack, > >       we are implementing this reader role through kolla-ansible. Need > help in understanding the policy file for adding custom role both in > nova and keystone. You can learn how to use the policy file directly by reading the docs I linked earlier: * https://docs.openstack.org/security-guide/identity/policies.html * https://docs.openstack.org/oslo.policy/train/admin/policy-json-file.html And then the APIs you can control access to in nova are shown in this sample file: * https://docs.openstack.org/nova/train/configuration/sample-policy.html APIs in keystone are shown in this sample file: * https://docs.openstack.org/keystone/train/configuration/samples/policy-yaml.html I'm afraid I don't know anything about how to adjust the policy file through kolla-ansible though. Cheers, -melanie > ---- On Fri, 02 Oct 2020 02:12:39 +0530 *melanie witt > * wrote ---- > > On 9/25/20 07:25, Ben Nemec wrote: > > I don't believe that the reader role was respected by most > projects in > > Train. Moving every project to support it is still a work in > progress. > > This is true and for nova, we have added support for the reader role > beginning in the Ussuri release as part of this spec work: > > https://specs.openstack.org/openstack/nova-specs/specs/ussuri/implemented/policy-defaults-refresh.html > > > > Documentation: > > https://docs.openstack.org/nova/latest/configuration/policy-concepts.html > > > > To accomplish a read-only user in the Train release for nova, you can > DIY to a limited extent by creating custom roles and adjusting your > policy.json file [1][2] accordingly. There are separate policies for > GET/POST/PUT/DELETE in many cases so if you were to create a role > ReadWriteUser you could specify that for POST/PUT/DELETE APIs and > create > another role ReadOnlyUser and specify that for GET APIs. > > Hope this helps, > -melanie > > [1] > https://docs.openstack.org/nova/train/configuration/sample-policy.html > > > [2] https://docs.openstack.org/security-guide/identity/policies.html > > > > On 9/24/20 11:58 PM, its-openstack at zohocorp.com > wrote: > >> Dear Openstack, > >> > >> We have deployed openstack train branch. > >> > >> This mail is in regards to the default role in openstack. we are > >> trying to create a read-only user i.e, the said user can only > view in > >> the web portal(horizon)/using cli commands. > >> the user cannot create an instance or delete an instance , the same > >> with any resource. > >> > >> we created a user in a project test with reader role, but in > >> horizon/cli able to create and delete instance and similar to other > >> access also > >> if you so kindly help us fix this issue would be grateful. > >> > >> the commands used for creation > >> > >> > >> > >> $ openstack user create --domain default --password-prompt > >> test-reader at test.com > > > >> $ openstack role add --project test --user test-reader at test.com > > >> > reader > >> > >> > >> > >> Thanks and Regards > >> sysadmin > >> > >> > >> > >> > >> > > > > > From jesse at odyssey4.me Mon Nov 2 18:24:39 2020 From: jesse at odyssey4.me (Jesse Pretorius) Date: Mon, 2 Nov 2020 18:24:39 +0000 Subject: [tripleo] please avoid creating ansible playbooks that call modules for trivial tasks In-Reply-To: <5D235976-DD12-438C-8A64-4C4EE57BBA01@redhat.com> References: <0bea7456-e413-1f05-ce91-8b1738c8777b@redhat.com> <5D235976-DD12-438C-8A64-4C4EE57BBA01@redhat.com> Message-ID: <32567c8c6d46e8e6e5b8860243e15e405da39301.camel@odyssey4.me> On Mon, 2020-11-02 at 16:40 +0000, Sorin Sbarnea wrote: IMHO, roles (inside collections) do provide quite good abstraction layer as they allow us to change implementation without changing the API (the variables passed to the role). If the role uses an embedded module, external one or lots of tasks to achieve the same functionality it is an implementation details. At any point in time we can refactor the role internals and create new modules, swap them, .... without messing its consumption. I cannot say the same about playbooks, especially those that call modules directly. If they call roles, we should be fine. Good point. That reminds me - to really make roles work more like an API, we should also probably implement tests which determine whether the API is changing in an acceptable way. We'd have to agree what 'acceptable' looks like - at the very least, I would imagine that we should be enforcing the same inputs & results with changes being additive unless there's sufficient deprecation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssbarnea at redhat.com Mon Nov 2 18:29:18 2020 From: ssbarnea at redhat.com (Sorin Sbarnea) Date: Mon, 2 Nov 2020 18:29:18 +0000 Subject: [tripleo] please avoid creating ansible playbooks that call modules for trivial tasks In-Reply-To: <32567c8c6d46e8e6e5b8860243e15e405da39301.camel@odyssey4.me> References: <0bea7456-e413-1f05-ce91-8b1738c8777b@redhat.com> <5D235976-DD12-438C-8A64-4C4EE57BBA01@redhat.com> <32567c8c6d46e8e6e5b8860243e15e405da39301.camel@odyssey4.me> Message-ID: I would give zuul-jobs roles a good example of big repository with well defined policies about how to write roles, including requirements for variables names and ways to document arguments. There is already work done towards adding support in ansible for declaring in/out variables for roles. They will likely look similar to how module arguments are now documented and reside inside "meta" folder. Still, until then use of README inside each role looks like a decent solution. > On 2 Nov 2020, at 18:24, Jesse Pretorius wrote: > > t reminds me - to really make roles work more like an API, we should also probably implement tests which determine whether the API is changing in an acceptable way. We'd have to agree what 'acceptable' looks like - at the very least, I would imagine that we should be enforcing the From peter.matulis at canonical.com Mon Nov 2 19:05:02 2020 From: peter.matulis at canonical.com (Peter Matulis) Date: Mon, 2 Nov 2020 14:05:02 -0500 Subject: [charms] OpenStack Charms 20.10 release is now available Message-ID: The 20.10 release of the OpenStack Charms is now available. This release brings several new features to the existing OpenStack Charms deployments for Queens, Rocky, Stein, Train, Ussuri, Victoria and many stable combinations of Ubuntu + OpenStack. Please see the Release Notes for full details: https://docs.openstack.org/charm-guide/latest/2010.html == Highlights == * OpenStack Victoria OpenStack Victoria is now supported on Ubuntu 20.10 (natively) and Ubuntu 20.04 LTS (via UCA). * Gnocchi and external root CA for S3 The gnocchi charm now supports the configuration of an external root CA in the gnocchi units. This is useful when an encrypted S3 (storage backend) endpoint uses certificates that are not managed by Vault. * Arista - Supported releases The neutron-api-plugin-arista charm now supports all OpenStack releases starting with Queens. * Neutron Gateway and additional data on ports and bridges The neutron-gateway charm now marks the openvswitch ports and bridges it creates as managed by the charm. This allows for less riskier cleanup mechanisms to be implemented. * cinder charm: Allow specifying the default volume type The cinder charm can now set the default volume type. This is to support scenarios where multiple storage backends are being used with Cinder. * Action based migration from Neutron ML2+OVS to ML2+OVN New actions have been introduced to enable migration of a Neutron ML2+OVS based deployment to ML2+OVN. * New charm: ceph-iscsi The ceph-iscsi charm has been promoted to supported status. This charm implements the Ceph iSCSI gateway, which provides iSCSI targets backed by a Ceph cluster. == OpenStack Charms team == The OpenStack Charms team can be contacted on the #openstack-charms IRC channel on Freenode. == Thank you == Lots of thanks to the below 30 charm contributors who squashed 45 bugs, enabled support for a new release of OpenStack, improved documentation, and added exciting new functionality! Alex Kavanagh Andrea Ieri Andreas Jaeger Aurelien Lourot Chris MacNaughton Corey Bryant Dan Ardelean David Ames Dmitrii Shcherbakov Edin Sarajlic Edward Hope-Morley Felipe Reyes Frode Nordahl Gabriel Adrian Hemanth Nakkina James Page Jorge Niedbalski Liam Young Martin Kalcok Martin Kopec Marton Kiss Michael Quiniola Nobuto Murata Pedro Guimaraes Peter Matulis Ponnuvel Palaniyappan Rodrigo Barbieri Xav Paice camille.rodriguez zhhuabj -- OpenStack Charms Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Mon Nov 2 19:19:06 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 2 Nov 2020 19:19:06 +0000 Subject: [tripleo] please avoid creating ansible playbooks that call modules for trivial tasks In-Reply-To: References: <0bea7456-e413-1f05-ce91-8b1738c8777b@redhat.com> <5D235976-DD12-438C-8A64-4C4EE57BBA01@redhat.com> <32567c8c6d46e8e6e5b8860243e15e405da39301.camel@odyssey4.me> Message-ID: <20201102191906.zeys7mjelns52pvs@yuggoth.org> On 2020-11-02 18:29:18 +0000 (+0000), Sorin Sbarnea wrote: [...] > I would give zuul-jobs roles a good example of big repository with > well defined policies about how to write roles, including > requirements for variables names and ways to document arguments. [...] > use of README inside each role looks like a decent solution. [...] Also, with the help of a Sphinx extension, it allows us to generate fancy role documentation like this: https://zuul-ci.org/docs/zuul-jobs/container-roles.html I'd imagine once standardized metadata comes along, we'll support building documentation from that too/instead. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From helena at openstack.org Mon Nov 2 21:42:07 2020 From: helena at openstack.org (helena at openstack.org) Date: Mon, 2 Nov 2020 16:42:07 -0500 (EST) Subject: [ptl] Victoria Release Community Meeting In-Reply-To: <20201021082822.5cocsx4zhhxs7n3q@p1.internet.domowy> References: <1602712314.02751333@apps.rackspace.com> <1603213221.77557521@apps.rackspace.com> <20201021082822.5cocsx4zhhxs7n3q@p1.internet.domowy> Message-ID: <1604353327.602612275@apps.rackspace.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Project Updates Template (1).pptx Type: application/octet-stream Size: 791794 bytes Desc: not available URL: From skaplons at redhat.com Mon Nov 2 21:56:59 2020 From: skaplons at redhat.com (Slawek Kaplonski) Date: Mon, 02 Nov 2020 22:56:59 +0100 Subject: [Neutron] PTG summary Message-ID: <6315331.olFIrCdlcp@p1> Hi, Below is my summary of the Neutron team sessions which we had during the virtual PTG last week. Etherpad with notes from the discussions can be found at [1]. ## Retrospective of the Victoria cycle >From the good things during _Victoria_ cycle team pointed: * Complete 8 blueprints including the _Metadata over IPv6_ [2], * Improved feature parity in the OVN driver, * Good review velocity >From the not so good things we mentioned: * CI instability - average number of rechecks needed to merge patch in last year can be found at [3], * Too much "Red Hat" in the Neutron team - and percentage of the reviews (and patches) done by people from Red Hat is constantly increasing over last few cycles. As a main reason of that we pointed that it is hard to change companies way of thinking that dedicating developer to the upstream project means that they lose developer in downstream. * Migration of our CI and Zuul v3 took us a lot of time and effort - but good thing is that we accomplished that in the Victoria cycle :) During that session we also agreed on some action items for the Wallaby cycle: * keep talking about OVN details - Miguel Lavalle and me will work on some way to deliver talks about Neutron OVN backend and OVN internals to the community during next months. The idea is to maybe propose some talks ever 6 weeks or so. This may make ovn driver development more diverse and let operators to thing about migration to the ovn backend. ## Review of the existing meetings We reviewed list of our existing upstream meetings and discussed about ideas on how to increase number of attendees on the meetings. We decided to: * drop neutron-qos meeting as it's not needed anymore * advertise more meetings and meetings' agenda on the OpenStack mailing list - I will send reminders with links to the agenda before every meeting * Together with Lajos Katona we will give some introduction to the debugging of CI issues in Neutron* ## Support for old versions Bernard started discussion about support for the old releases in Neutron and Neutron stadium projects. For Neutron we decided to mark __Ocata__ branch as unmaintained already as its gate is already broken. For the __Pike__ and never branches we will keep them in the __EM__ phase as there is still some community interest to keep those branches open. For the stadium projects we decided to do it similary to what we did while looking for new maintainers for the projects. We will send email "call for maintainers" for such stable branches. If there will be no voluneers to step in, fix gate issues and keep those branches healthy, we will mark them as __unmaintained__ and later as __End of Life__ (EOL). Currently broken CI is in projects: * networking-sfc, * networking-bgpvpn/bagpipe, * neutron-fwaas And those are candidates to be marked as unmaintained if there will be no volunteers to fix them. Bernard Cafarelli volunteered to work on that in next days/weeks. ## Healtcheck API endpoint We discussed as our healtcheck API should works. During the discussion we decided that: * healtcheck result should __NOT__ rely on the agents status, it should rely on worker's ability to connect to the DB and MQ (rabbitmq) * Lajos will ask community (API experts) about some guidance how it should works on the whole OpenStack level, * As for reference implementation we can check e.g. Octavia [4] and Keystone [5] which already implemented it. ## Squash of the DB migration script Rodolfo explained us what are benefits of doing such squash of the db migration scripts from the old versions: * Deployment is faster: we don't need to create/delete tables or create+update other ones - the win is small possibly in the magnitude of 5s per job, * DB definition is centralized in one place, not in original definition plus further migrations - that is most important reason why we really should do that, * UTs faster: removal of some older checks. The problem with this may be that we need to do that carefully and be really verbose about with such changes we may break stadium projects or 3rd party projects which are doing db migration too. To minimalize potential breakage, we will announce such changes on the OpenStack discuss mailing list. Rodolfo volunteered to take propose squash up to Liberty release in W cycle. Together with this squash we will also document that process so in next cycles we should be able to do squashes for newer releases in easier way. Lajos volunteered to help with fixing Neutron stadium projects if that will be needed. ## Switch to the new engine facade We were discussing how to move on and finally finish old Blueprint [6]. We decided that together with Rodolfo we will try how this new engine facade will work without using transaction guards in the code. Hopefully that will let us move on with this. If not, we will try to reach out to some DB experts for some help with this. ## Change from rootwrap to the privsep This is now community goal during the Wallaby cycle so we need to focus on it to accomplish that transition finally. This transition may speed up and make our code a bit more secure. Rodolfo explained us multiple possible strategies of migration: * move to native, e.g. * replace ps with python psutils, not using rootwrap or privsep * replace ip commands with pyroute2, under a privsep context (elevated permissions needed) * directly translate rootwrap to privsep, executing the same shell command but under a privsep context To move on with this I will create list of the pieces of code which needs to be transitioned in the Neutron repo and in the stadium projects. Current todo items can be found on the storyboard [7]. ## Migration to the NFtables During this session we were discussing potential strategies on how to migrate from the old iptables to the new nftables. We need to start planning that work as it major Linux distributions (e.g. RHEL) are planning to deprecate iptables in next releases. It seems that currently all major distros (Ubuntu, Centos, OpenSuSE) supports nftables already. We decided that in Wallaby cycle we will propose new _Manager_ class and we will add some config option which will allow people to test new solution. In next cycles we will continue work on it to make it stable and to make upgrade and migration path for users as easy as possible. There is already created blueprint to track progress on that topic [8]. We need to migrate: * Linuxbridge firewall, iptables OVS hybrid firewall, * L3 code (legacy router, DVR router, conntrack, port forwarding), * iptables metering, * metadata proxy, * dhcp agent for when it does metadata for isolated networks and namespace creation, * neutron-vpnaas - ipsec code, * and maybe something else what we didn't found yet. ## Nova-Neutron cross project session We had very interesting discussion with Nova team. We were discussing topics like: * NUMA affinity in the neutron port * vhost-vdpa support * default __vnic_type__/__port flavour__ Notes from that discussion are available in the nova's etherpad [9]. ## Neutron scalling issues At this session we were discussing issues mentioned by operators on the Forum sessions a week before the PTG. There was couple of issues mentioned there: * problems with retries of the DB operations - we should migrate all our code to the oslo.db retries mechanism - new blueprint [10] is created to track progress on that one. * problems with maintenance of the agents, like e.g. DHCP or L3 agents - many of those issues are caused by how our agents are designed and to really fix that we would need very deep and huge changes. But also many of those issues can be solved by the __ovn__ backend - **and that is strategic direction in which neutron wants to go in the next cycles**, * Miguel Lavalle and I volunteered to do some profiling of the agents to see where we are loosing most of the time - maybe we will be able to find some _low hanging fruits_ which can be fixed and improve the situation at least a bit, * Similar problem with neutron-ovs-agent and especially security groups which are using _remove group id_ as a reference - here we also need some volunteers who will try to optimize that. ## CI (in)stablility On Thursday we were discussing how to improve our very poor CI. Finally we decided to: * not recheck patches without giving reason of recheck in the comment - there should be already reported bug which should be linked in the _recheck_ comment, or user should open new one and link to it also. IN case if the problem was e.g. related to infra some simple comment like _infra issue_ will also be enough there, * To lower number of existing jobs we will do some changes like: * move *-neutron-lib-master and *-ovs-master jobs to the experimental and periodic queues to not run them on every patch, * I will switch _neutron-tempest-plugin-api_ job to be deployed with uwsgi so we can drop _neutron-tempest-with-uwsgi_ job, * Consolidate _neutron-tempest-plugin-scenario-linuxbridge_ and _neutron- tempest-linuxbridge_ jobs, * Consolidate _neutron-tempest-plugin-scenario-iptables_hybrid and _neutron- tempest-iptables_hybrid jobs, Later we also discussed about the way how to run or skip tests which can be only run when some specific feature is available in the cloud (e.g. _Metadata over IPv6_). After some discussion we decided to add new config option with list of enabled features. It will be very similar to the existing option _api_extensions_. Lajos volunteered to work on that. As last CI related topic we discussed about testing DVR in our CI. Oleg Bondarev volunteered to check and try to fix broken _neutron-tempest-plugin- dvr-multinode-scenario_ job. ## Flow based DHCP Liu Yulong raised topic about new way of doing fully distributed DHCP service, instead of using _DHCP agent_ on the nodes - RFE is proposed at [11]. His proposal of doing Open Flow based DHCP (similar to what e.g. ovn-controller is doing) is described in [12]. It could be implemented as an L2 agent extension and enabled by operators in the config when they would need it. As a next step Liu will now propose spec with details about this solution and we will continue discussion about it in the spec's review. ## Routed provider networks limited to one host As a lost topic on Thursday we briefly talked about old RFE [13]. Miguel Lavalle told us that his company, Verizon Media, is interested in working on this RFE in next cycles. This also involves some work on Nova's side which was started by Sylvain Bauza already. Miguel will sync with Sylvain on that RFE. ## L3 feature improvements On Friday we were discussing some potential improvements in the L3 area. Lajos and Bence shown us some features which their company is interested in and on which they plan to work. Those are things like: * support for Bidirectional Forwarding Detection * some additional API to set additional router parameters like: * ECMP max path, * ECMP hash algorith * --provider-allocation-pool parameter in the subnets - in some specific cases it may help to use IPs from such _special_ pool for some infrastructure needs, more details about that will come in the RFE in future, For now all those described above improvements are in very early planning phase but Bence will sync with Liu and Liu will dedicate some time to discuss progress on them during the __L3 subteam meetings__. ## Leveraging routing-on-the-host in Neutron in our next-gen clusters As a last topic on Friday we were discussing potential solutions of the _L3 on the host_ in the Neutron. The idea here is very similar to what e.g. __Calico plugin__ is doing currently. More details about potential solutions are described in the etherpad [14]. During the discussion Dawid Deja from OVH told us that OVH is also using very similar, downstream only solution. Conclusion of that discussion was that we may have most of the needed code already in Neutron and some stadium projects so as a first step people who are interested in that topic, like Jan Gutter, Miguel and Dawid will work on some deployment guide for such use case. ## Team photo During the PTG we also made team photos which You can find at [15]. [1] https://etherpad.opendev.org/p/neutron-wallaby-ptg [2] https://blueprints.launchpad.net/neutron/+spec/metadata-over-ipv6 [3] https://ibb.co/12sB9N9 [4] https://opendev.org/openstack/octavia/src/branch/master/octavia/api/ healthcheck/healthcheck_plugins.py [5] https://docs.openstack.org/keystone/victoria/admin/health-check-middleware.html [6] https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch [7] https://storyboard.openstack.org/#!/story/2007686 [8] https://blueprints.launchpad.net/neutron/+spec/nftables-migration [9] https://etherpad.opendev.org/p/nova-wallaby-ptg [10] https://blueprints.launchpad.net/neutron/+spec/oslo-db-retries [11] https://bugs.launchpad.net/neutron/+bug/1900934 [12] https://github.com/gotostack/shanghai_ptg/blob/master/ shanghai_neutron_ptg_topics_liuyulong.pdf [13] https://bugs.launchpad.net/neutron/+bug/1764738 [14] https://etherpad.opendev.org/p/neutron-routing-on-the-host [15] http://kaplonski.pl/files/Neutron_virtual_PTG_October_2020.tar.gz -- Slawek Kaplonski Principal Software Engineer Red Hat From zigo at debian.org Mon Nov 2 22:59:58 2020 From: zigo at debian.org (Thomas Goirand) Date: Mon, 2 Nov 2020 23:59:58 +0100 Subject: [Neutron] PTG summary In-Reply-To: <6315331.olFIrCdlcp@p1> References: <6315331.olFIrCdlcp@p1> Message-ID: <16c52015-e038-317b-27b7-4831987efa1b@debian.org> Hi Slawek, Thanks a lot for the summary, that's very useful. On 11/2/20 10:56 PM, Slawek Kaplonski wrote: > * replace ip commands with pyroute2, under a privsep context (elevated > permissions needed) Please, please, please, do this, and give it some high priority. Spawning thousands of times the ip command simply doesn't scale. > ## Migration to the NFtables > During this session we were discussing potential strategies on how to migrate > from the old iptables to the new nftables. We need to start planning that work > as it major Linux distributions (e.g. RHEL) are planning to deprecate iptables > in next releases. Did you know that Debian uses nftables by default since Buster, and that one must set iptables-legacy as alternative, otherwise Neutron becomes mad and fails applying firewall rules? I'm not sure about Bullseye, but maybe there, iptables-legacy will even be gone?!? > ## Leveraging routing-on-the-host in Neutron in our next-gen clusters > > As a last topic on Friday we were discussing potential solutions of the _L3 on > the host_ in the Neutron. The idea here is very similar to what e.g. __Calico > plugin__ is doing currently. > More details about potential solutions are described in the etherpad [14]. > During the discussion Dawid Deja from OVH told us that OVH is also using very > similar, downstream only solution. > Conclusion of that discussion was that we may have most of the needed code > already in Neutron and some stadium projects so as a first step people who are > interested in that topic, like Jan Gutter, Miguel and Dawid will work on some > deployment guide for such use case. It'd be great if people were sharing code for this. I've seen at least 3 or 4 companies doing it, none sharing any bits... :/ How well is the Calico plugin working for this? Do we know? Has anyone tried it in production? Does it scale well? Cheers, Thomas Goirand (zigo) From changzhi at cn.ibm.com Tue Nov 3 05:51:06 2020 From: changzhi at cn.ibm.com (Zhi CZ Chang) Date: Tue, 3 Nov 2020 05:51:06 +0000 Subject: [nova] Why nova needs password-less SSH to do live migraiton? Message-ID: An HTML attachment was scrubbed... URL: From zigo at debian.org Tue Nov 3 07:48:39 2020 From: zigo at debian.org (Thomas Goirand) Date: Tue, 3 Nov 2020 08:48:39 +0100 Subject: [nova] Why nova needs password-less SSH to do live migraiton? In-Reply-To: References: Message-ID: <2462c573-0a7a-8a27-b637-aadaba911580@debian.org> On 11/3/20 6:51 AM, Zhi CZ Chang wrote: > Hi, all >   > In the nova live migration doc[1], there is some description of libvirt > configuration: > " > Enable password-less SSH so that root on one compute host can log on to > any other compute host without providing a password. > The |libvirtd| daemon, which runs as root, uses the SSH protocol to copy > the instance to the destination and can’t know the passwords of all > compute hosts. > " > According to the description, I understand that the libvirtd daemon runs > as the root user for remote copy the instance to the destination. >   > My question is, why make the libvirtd daemon runs as the "root" user for > copy instance rather than other users, like the "nova" user? >   >   > Thanks > Zhi Chang Hi, What's needed is password-less (ie: key authentication) under the nova user, not root. What I did was having the ssh host keys signed, so that nodes can authenticate with each other in a secure way. I strongly recommend doing that, instead of blindly trusting ssh keys, which could potentially mean someone could be in the middle. Cheers, Thomas Goirand (zigo) From changzhi at cn.ibm.com Tue Nov 3 08:18:14 2020 From: changzhi at cn.ibm.com (Zhi CZ Chang) Date: Tue, 3 Nov 2020 08:18:14 +0000 Subject: [nova] Why nova needs password-less SSH to do live migraiton? In-Reply-To: <2462c573-0a7a-8a27-b637-aadaba911580@debian.org> References: <2462c573-0a7a-8a27-b637-aadaba911580@debian.org>, Message-ID: An HTML attachment was scrubbed... URL: From bence.romsics at gmail.com Tue Nov 3 10:23:14 2020 From: bence.romsics at gmail.com (Bence Romsics) Date: Tue, 3 Nov 2020 11:23:14 +0100 Subject: [neutron] bug deputy report for week of 2020-10-26 Message-ID: Hi Team, We had the following new bugs on the week of the PTG. Sorry for sending the report a bit late. Critical: * https://bugs.launchpad.net/neutron/+bug/1901534 Neutron fail to create networks because of MTU value changes proposed: https://review.opendev.org/#/q/topic:bug/1901534 Medium: * https://bugs.launchpad.net/neutron/+bug/1901527 Agent API gets broken if OVN DB is upgraded to the one introducing chassis_private change series proposed: https://review.opendev.org/#/q/topic:bug/1901527 * https://bugs.launchpad.net/neutron/+bug/1901992 Original default route in DVR SNAT namespace is not recovered after creating and deleting /0 extraroute The first fix proposed won't work since it would have been an API change. No fix proposed for the re-stated problem (bug comments #4 and #7) at the moment. * https://bugs.launchpad.net/neutron/+bug/1902512 neutron-ovn-tripleo-ci-centos-8-containers-multinode fails on private networ creation (mtu size) unassigned Low: * https://bugs.launchpad.net/neutron/+bug/1901936 [OVN Octavia Provider] OVN provider loadbalancer failover should fail as unsupported fix proposed: https://review.opendev.org/760209 Incomplete: * https://bugs.launchpad.net/neutron/+bug/1902211 Router State standby on all l3 agent when create Looks vpnaas related. The reporter is asking for help in debugging a lock that's never released. Not reproducible at will at the moment. * https://bugs.launchpad.net/neutron/+bug/1901707 race condition on port binding vs instance being resumed for live-migrations Broken out of https://bugs.launchpad.net/neutron/+bug/1815989. * https://bugs.launchpad.net/neutron/+bug/1463631 60_nova/resources.sh:106:ping_check_public fails intermittently Sporadic re-appearance of an ages old bug, with hardly enough information to reproduce at will. Cheers, Bence From zigo at debian.org Tue Nov 3 10:26:27 2020 From: zigo at debian.org (Thomas Goirand) Date: Tue, 3 Nov 2020 11:26:27 +0100 Subject: [nova] Why nova needs password-less SSH to do live migraiton? In-Reply-To: References: <2462c573-0a7a-8a27-b637-aadaba911580@debian.org> Message-ID: <9fb653f8-026d-d1de-8be6-6e7e39fca209@debian.org> On 11/3/20 9:18 AM, Zhi CZ Chang wrote: > Hi, Thomas >   > Thanks for your reply. >   > In your environment, you use the "root" user for authenticating with > each other compute node, rather than the "nova" user, right? > If so, why use the "root" user rather than the "nova" user then > privilege the root permission to the "nova" user? >   > Thanks > Zhi Chang Hi, No, the username is "nova", not "root". Thomas Goirand (zigo) P.S: Please don't CC me, I'm registered to the list. From changzhi at cn.ibm.com Tue Nov 3 11:15:45 2020 From: changzhi at cn.ibm.com (Zhi CZ Chang) Date: Tue, 3 Nov 2020 11:15:45 +0000 Subject: [nova] Why nova needs password-less SSH to do live migraiton? In-Reply-To: <9fb653f8-026d-d1de-8be6-6e7e39fca209@debian.org> References: <9fb653f8-026d-d1de-8be6-6e7e39fca209@debian.org>, <2462c573-0a7a-8a27-b637-aadaba911580@debian.org> Message-ID: An HTML attachment was scrubbed... URL: From skaplons at redhat.com Tue Nov 3 11:24:13 2020 From: skaplons at redhat.com (Slawek Kaplonski) Date: Tue, 03 Nov 2020 12:24:13 +0100 Subject: [neutron][core team] (Re)adding Oleg Bondarev to the Neutron core team Message-ID: <3552015.USbqv0nN58@p1> Hi, I'm glad to announce that I just fast-tracked back Oleg to the Neutron core team. Oleg was Neutron core in the past and now, since few months he is again one of the most active Neutron reviewers [1]. Welcome back in the core team Oleg :) [1] https://www.stackalytics.com/report/contribution/neutron-group/90 -- Slawek Kaplonski Principal Software Engineer Red Hat From ralonsoh at redhat.com Tue Nov 3 11:32:24 2020 From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez) Date: Tue, 3 Nov 2020 12:32:24 +0100 Subject: [neutron][core team] (Re)adding Oleg Bondarev to the Neutron core team In-Reply-To: <3552015.USbqv0nN58@p1> References: <3552015.USbqv0nN58@p1> Message-ID: Welcome back Oleg! On Tue, Nov 3, 2020 at 12:28 PM Slawek Kaplonski wrote: > Hi, > > I'm glad to announce that I just fast-tracked back Oleg to the Neutron > core > team. > Oleg was Neutron core in the past and now, since few months he is again > one of > the most active Neutron reviewers [1]. > Welcome back in the core team Oleg :) > > [1] https://www.stackalytics.com/report/contribution/neutron-group/90 > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yumeng_bao at yahoo.com Tue Nov 3 11:36:43 2020 From: yumeng_bao at yahoo.com (yumeng bao) Date: Tue, 3 Nov 2020 19:36:43 +0800 Subject: [cyborg] PTG Summary and Wallaby Release Schedule References: Message-ID: Hi all, Thank you all for the PTG participation! All our agreements and decisions are marked in the etherpad[1] with AGREED word. And I have proposed the Wallaby_Release_Schedule[2] on Cyborg wiki page to track features with milestone. [1]https://etherpad.opendev.org/p/cyborg-wallaby-goals [2]https://wiki.openstack.org/wiki/Cyborg/Wallaby_Release_Schedule Regards, Yumeng From katonalala at gmail.com Tue Nov 3 12:02:19 2020 From: katonalala at gmail.com (Lajos Katona) Date: Tue, 3 Nov 2020 13:02:19 +0100 Subject: [neutron][core team] (Re)adding Oleg Bondarev to the Neutron core team In-Reply-To: <3552015.USbqv0nN58@p1> References: <3552015.USbqv0nN58@p1> Message-ID: Well earned Slawek Kaplonski ezt írta (időpont: 2020. nov. 3., K, 12:25): > Hi, > > I'm glad to announce that I just fast-tracked back Oleg to the Neutron > core > team. > Oleg was Neutron core in the past and now, since few months he is again > one of > the most active Neutron reviewers [1]. > Welcome back in the core team Oleg :) > > [1] https://www.stackalytics.com/report/contribution/neutron-group/90 > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at est.tech Tue Nov 3 12:08:54 2020 From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer) Date: Tue, 03 Nov 2020 13:08:54 +0100 Subject: [placement][nova][cinder][neutron][blazar][tc][zun] Placement governance switch(back) In-Reply-To: <56f987f0-20a5-7163-062e-9e02a0f99057@openstack.org> References: <51776398bc77d6ec24a230ab4c2a5913@sslemail.net> <3e09b1015433411e9752d3543d63d331@inspur.com> <56f987f0-20a5-7163-062e-9e02a0f99057@openstack.org> Message-ID: Hi, Sorry for the top post but I want to give a summary where we are with the Placement governance question. During the PTG both the TC and the Nova teams discussed the situation. We decided if there is no volunteers for the rest of the needed liaisons until the end of the PTG then we move the Placement project under Nova governance. As we hit that deadline I've proposed the governance patch[1]. Cheers, gibi [1] https://review.opendev.org/#/c/760917 On Tue, Oct 13, 2020 at 11:34, Thierry Carrez wrote: > Brin Zhang(张百林) wrote: >> Hi, gibi, I am a contributor for nova and placement, and do many >> feature from Stein release, I would like to take on the role of >> *Release liaison*[1] in Placement to help more people. > > Thanks Brin Zhang for volunteering! > > We still need (at least) one volunteer for security liaison and one > volunteer for TaCT SIG (infra) liaison. > > Anyone else interested in helping? > > -- > Thierry Carrez (ttx) > From skaplons at redhat.com Tue Nov 3 12:25:27 2020 From: skaplons at redhat.com (Slawek Kaplonski) Date: Tue, 03 Nov 2020 13:25:27 +0100 Subject: [neutron] Team meeting Message-ID: <10236937.s4mitKBmyh@p1> Hi, Just a quick reminder. Today at 14:00 UTC we will have neutron team meeting in the #openstack-meeting-3 room @freenode. Meeting's agenda is available in [1]. If You have any topics which You want to discuss, please add them to the "On demand" section. See You all at the meeting :) [1] https://wiki.openstack.org/wiki/Network/Meetings -- Slawek Kaplonski Principal Software Engineer Red Hat From bdobreli at redhat.com Tue Nov 3 13:11:26 2020 From: bdobreli at redhat.com (Bogdan Dobrelya) Date: Tue, 3 Nov 2020 14:11:26 +0100 Subject: [tripleo][ci] Monday Nov 2 In-Reply-To: References: Message-ID: <0b8e1c52-640d-9370-981d-c6db3814626c@redhat.com> On 10/30/20 6:31 PM, Wesley Hayutin wrote: > Greetings, > > The tripleo ci team has identified a handful of patches that we'd like > to land prior to Nov 2, the day docker.io goes away. >  We've hit some new bugs and have also tuned a few things to try and > make sure we can get patches to merge. > > Our current focus is across master, victoria, ussuri and centos-8 train, > and queens while reducing coverage in rocky and stein. > > A list of the prioritized gerrit reviews can be found here: > https://hackmd.io/MlbZ_izSTEuZsCWTJvu_Kg?view > > The entire topic can be found here: > https://review.opendev.org/#/q/topic:new-ci-job In that list there are patches to puppet modules and openstack services what run a single standalone tripleo CI job. I don't think creating an extra provider job to run a single consumer job sounds reasonable. > > Thanks all. -- Best regards, Bogdan Dobrelya, Irc #bogdando From tpb at dyncloud.net Tue Nov 3 15:10:29 2020 From: tpb at dyncloud.net (Tom Barron) Date: Tue, 3 Nov 2020 10:10:29 -0500 Subject: Which deployment method for ceph (rook|ceph-ansible|tripleo) In-Reply-To: <16c93e9a-765e-f254-a915-8e92fb6a7dcb@me.com> References: <16c93e9a-765e-f254-a915-8e92fb6a7dcb@me.com> Message-ID: <20201103151029.dyixpfoput5rgyae@barron.net> On 01/11/20 08:55 +0100, Oliver Weinmann wrote: >Hi, > >I'm still in the process of preparing a OpenStack POC. I'm 100% sure >that I want to use CEPH and so I purchased the book Mastering CEPH 2nd >edition. First of all, It's a really good book. It basically explains >the various methods how ceph can be deployed and also the components >that CEPH is build of. So I played around a lot with ceph-ansible and >rook in my virtualbox environment. I also started to play with tripleo >ceph deployment, although I haven't had the time yet to sucessfully >deploy a openstack cluster with CEPH. Now I'm wondering, which of >these 3 methods should I use? > >rook > >ceph-ansible > >tripleo > >I also want to use CEPH for NFS and CIFS (Samba) as we have plenty of >VMs running under vSphere that currently consume storage from a ZFS >storage via CIFS and NFS. I don't know if rook can be used for this. I >have the feeling that it is purely meant to be used for kubernetes? >And If I would like to have CIFS and NFS maybe tripleo is not capable >of enabling these features in CEPH? So I would be left with >ceph-ansible? > >Any suggestions are very welcome. > >Best Regards, > >Oliver > > If your core use case is OpenStack (OpenStack POC with CEPH) then of the three tools mentioned only tripleo will deploy OpenStack. It can deploy a Ceph cluster for use by OpenStack as well, or you can deploy Ceph externally and it will "point" to it from OpenStack. For an OpenStack POC (and maybe for production too) I'd just have TripleO deploy the Ceph cluster as well. TripleO will use a Ceph deployment tool -- today, ceph-ansible; in the future, cephadm -- to do the actual Ceph cluster deployment but it figures out how to run the Ceph deployment for you. I don't think any of these tools will install a Samba/CIFs gateway to CephFS. It's reportedly on the road map for the new cephadm tool. You may be able to manually retrofit it to your Ceph cluster by consulting upstream guidance such as [1]. NFS shares provisioned in OpenStack (Manila file service) *could* be shared out-of-cloud to VSphere VMs if networking is set up to make them accessible but the shares would remain OpenStack managed. To use the same Ceph cluster for OpenStack and vSphere but have separate storage pools behind them, and independent management, you'd need to deploy the Ceph cluster independently of OpenStack and vSphere. TripleO could "point" to this cluster as mentioned previously. I agree with your assessment that rook is intended to provide PVs for Kubernetes consumers. You didn't mention Kubernetes as a use case, but as John Fulton has mentioned it is possible to use rook on Kubernetes in a mode where it "points" to an external ceph cluster rather than provisioning its own as well. Or if you run k8s clusters on OpenStack, they can just consume the OpenStack storage, which will be Ceph storage when that is used to back OpenStack Cinder and Manila. -- Tom Barron [1] https://www.youtube.com/watch?v=5v8L7FhIyOw&list=PLrBUGiINAakNCnQUosh63LpHbf84vegNu&index=19&t=0s&app=desktop From rosmaita.fossdev at gmail.com Tue Nov 3 15:21:53 2020 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Tue, 3 Nov 2020 10:21:53 -0500 Subject: [cinder] reminder: weekly meeting wednesday 4 nov at 1400utc Message-ID: <2ac365c4-3e07-a6f1-0b54-819478782717@gmail.com> After two weeks of not having meetings due to summit/forum/ptg, the cinder team will be holding its weekly meeting at the usual time (1400 UTC) and location (#openstack-meeting-alt) tomorrow (wednesday 4 november). People who had been following daylight saving (or summer) time until recently, keep in mind that although the UTC time of the meeting has not changed, it may be an hour earlier for you in your local time. cheers, brian From whayutin at redhat.com Tue Nov 3 15:30:00 2020 From: whayutin at redhat.com (Wesley Hayutin) Date: Tue, 3 Nov 2020 08:30:00 -0700 Subject: [tripleo][ci] Monday Nov 2 In-Reply-To: <0b8e1c52-640d-9370-981d-c6db3814626c@redhat.com> References: <0b8e1c52-640d-9370-981d-c6db3814626c@redhat.com> Message-ID: On Tue, Nov 3, 2020 at 6:20 AM Bogdan Dobrelya wrote: > On 10/30/20 6:31 PM, Wesley Hayutin wrote: > > Greetings, > > > > The tripleo ci team has identified a handful of patches that we'd like > > to land prior to Nov 2, the day docker.io goes > away. > > We've hit some new bugs and have also tuned a few things to try and > > make sure we can get patches to merge. > > > > Our current focus is across master, victoria, ussuri and centos-8 train, > > and queens while reducing coverage in rocky and stein. > > > > A list of the prioritized gerrit reviews can be found here: > > https://hackmd.io/MlbZ_izSTEuZsCWTJvu_Kg?view > > > > The entire topic can be found here: > > https://review.opendev.org/#/q/topic:new-ci-job > > In that list there are patches to puppet modules and openstack services > what run a single standalone tripleo CI job. I don't think creating an > extra provider job to run a single consumer job sounds reasonable. > > > > > Thanks all. > So our first pass there I think should be a content-provider. However we could potentially drop the content-provider and override docker.io -> quay.io as well. We are not certain yet how well quay.io will perform so we're being cautious atm. > > > -- > Best regards, > Bogdan Dobrelya, > Irc #bogdando > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From knikolla at bu.edu Tue Nov 3 15:31:12 2020 From: knikolla at bu.edu (Nikolla, Kristi) Date: Tue, 3 Nov 2020 15:31:12 +0000 Subject: [keystone] No keystone team meeting Nov 3 Message-ID: <703CF7AD-7036-4DFD-AACD-9F51F06F4F00@bu.edu> Hi all, There will be no keystone team meeting on IRC today, on November 3rd. Best, Kristi From gagehugo at gmail.com Tue Nov 3 15:33:02 2020 From: gagehugo at gmail.com (Gage Hugo) Date: Tue, 3 Nov 2020 09:33:02 -0600 Subject: [openstack-helm] No OSH meeting today Message-ID: Hello, the meeting for today has been cancelled, we will meet next week. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marios at redhat.com Tue Nov 3 15:43:12 2020 From: marios at redhat.com (Marios Andreou) Date: Tue, 3 Nov 2020 17:43:12 +0200 Subject: [tripleo][ci] Monday Nov 2 In-Reply-To: References: <0b8e1c52-640d-9370-981d-c6db3814626c@redhat.com> Message-ID: On Tue, Nov 3, 2020 at 5:31 PM Wesley Hayutin wrote: > > > On Tue, Nov 3, 2020 at 6:20 AM Bogdan Dobrelya > wrote: > >> On 10/30/20 6:31 PM, Wesley Hayutin wrote: >> > Greetings, >> > >> > The tripleo ci team has identified a handful of patches that we'd like >> > to land prior to Nov 2, the day docker.io goes >> away. >> > We've hit some new bugs and have also tuned a few things to try and >> > make sure we can get patches to merge. >> > >> > Our current focus is across master, victoria, ussuri and centos-8 >> train, >> > and queens while reducing coverage in rocky and stein. >> > >> > A list of the prioritized gerrit reviews can be found here: >> > https://hackmd.io/MlbZ_izSTEuZsCWTJvu_Kg?view >> > >> > The entire topic can be found here: >> > https://review.opendev.org/#/q/topic:new-ci-job >> >> In that list there are patches to puppet modules and openstack services >> what run a single standalone tripleo CI job. I don't think creating an >> extra provider job to run a single consumer job sounds reasonable. >> >> > >> > Thanks all. >> > > So our first pass there I think should be a content-provider. However we > could potentially drop the content-provider and override docker.io -> > quay.io as well. We are not certain yet how well quay.io will perform so > we're being cautious atm. > > or as currently discussing with sshnaidm on irc the job itself can build the containers instead of having a content provider do that 17:38 < sshnaidm|rover> maybe in puppet repos we will just build containers? 17:38 < sshnaidm|rover> it's one standalone job there only, irrc 17:38 < sshnaidm|rover> I think bogdan is right 17:39 < marios> sshnaidm|rover: but is it worth it to special case that? in the end it is still just 'build one set of containers' does it matter if it happens in a content provider or in the job itself? I guess it depends how stable are the cotnent providers and the answer is 'not always' ... :/ 17:40 < sshnaidm|rover> marios, it will remain one job there, not two 17:40 < sshnaidm|rover> and no need to change layouts, just adding one variable 17:40 < sshnaidm|rover> these repos anyway don't expect to run anything else from tripleo 17:41 < sshnaidm|rover> ~10 repos * N branches, will save us a little work.. 17:41 < marios> sshnaidm|rover: ack ... if it is easy enough to have that as special case then OK. and yes having one job instead of 2 (one content provider) brings its own benefits > > > >> >> >> -- >> Best regards, >> Bogdan Dobrelya, >> Irc #bogdando >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Tue Nov 3 16:11:55 2020 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Tue, 3 Nov 2020 17:11:55 +0100 Subject: [masakari] Wallaby PTG Summary Message-ID: Hello Everyone! Masakari had 3 2-hour sessions and we managed to discuss a broad range of proposals and assign tasks to interested parties. (And this was my first time chairing a PTG as PTL). Thank you, everyone who participated! Here is a summary of the PTG discussions. The whole discussion has been written down in the etherpad. [1] We acknowledged that the project has lost its momentum during the last cycle (Victoria) and we hope to restore it now. To this end, we are reviving interesting old blueprints and specs. Some of these are already at the implementation stage, ready for reviews. Some of the discussed proposals fall into the 'low code impact, high (positive) usability impact' category, the most prominent being ways to have more flexibility in disabling/enabling the HA scope as well as generally more friendly approach towards user errors (not evacuating 'pinned' instances). On the other hand, some proposals involve deeper architectural changes to Masakari, such as the shift from reliance on Pacemaker/Corosync stack to Consul and/or etcd (possibly also for coordination), as well as making Masakari inspect the host status via both inbound and outbound means (including power management for checks and fencing). To this end, we plan to investigate a possible integration with Ironic as our gate to the baremetal world. Another proposal worth noting is the Masakari 'restore previous state' workflow, meant to help operators move instances back to their original location once the local problem is solved. Yet another proposal is increasing the resilience under the current scope (Pacemaker/Corosync) by retrying host checks (several sampled observations rather than one) and implementing adaptive rules to consider large-scale failures. We also discussed general maintenance tasks. We decided to give some love to the documentation and make sure it's not self-contradictory and also in agreement with the actual code, as well as include general recommendation on how Masakari is supposed to be deployed to have it work optimally. Finally, we discussed a few miscellaneous proposals such as making Masakari a better container world citizen by removing the reliance on systemd. [1] https://etherpad.opendev.org/p/masakari-wallaby-vptg Kind regards, -yoctozepto From dtantsur at redhat.com Tue Nov 3 16:41:13 2020 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Tue, 3 Nov 2020 17:41:13 +0100 Subject: [ironic] Configuration mold follow-up In-Reply-To: References: Message-ID: Hi Aija, On Mon, Nov 2, 2020 at 1:55 PM Jaunteva, Aija wrote: > Hi, > > > > to follow up on Ironic PTG session about Configuration molds [1] I’m > scheduling a call to discuss remaining items (mainly storage of the molds). > Honestly, I feel like it's a bit premature to discuss the potential storage of the molds until we get the first version out and tested in the wild. Dmitry > > > Anyone interested please add your availability in Doodle [2]. > > When time slot decided, will share call details. > > > > Regards, > > Aija > > > > [1] https://etherpad.opendev.org/p/ironic-wallaby-ptg line 216 > > [2] https://doodle.com/poll/dry4x5tbmhi6x6p3 > -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Tue Nov 3 19:25:23 2020 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 03 Nov 2020 13:25:23 -0600 Subject: [qa][policy] Testing strategy discussion for new RBAC (new scope and default role combinations) Message-ID: <1758f922fe5.b2f4514a220341.5965440098876721164@ghanshyammann.com> Hello Everyone, To continue the discussion on how projects should test the new RBAC (scope as well as the new defaults combination), we will host a call on bluejeans on Tuesday 10th Nov 16.00 UTC. Lance has set up the room for that: https://bluejeans.com/749897818 Feel free to join if you are interested in that or would like to help with this effort. -gmann From oliver.weinmann at me.com Tue Nov 3 20:05:01 2020 From: oliver.weinmann at me.com (Oliver Weinmann) Date: Tue, 3 Nov 2020 21:05:01 +0100 Subject: Which deployment method for ceph (rook|ceph-ansible|tripleo) In-Reply-To: <20201103151029.dyixpfoput5rgyae@barron.net> References: <20201103151029.dyixpfoput5rgyae@barron.net> Message-ID: <3BF6161C-B8D5-46E1-ACA3-3516BE901D1F@me.com> Hi Tom, Thanks a lot for your input. Highly appreciated. John really convinced me to deploy a Standalone cluster with cephadm and so I started to deploy It. I stumbled upon a few obstacles, but mostly because commands didn’t behave as expected or myself missing some important steps like adding 3 dashes in a yml file. Cephadm looks really promising. I hope that by tomorrow I will have a simple 3 node cluster. I have to look deeper into it as of how to configure separate networks for the cluster and the Frontend but it shouldn’t be too hard. Once the cluster is functioning I will re-deploy my tripleo POC pointing to the standalone Ceph cluster. Currently I have a zfs nfs Storage configured that I would like to keep. I have to figure out how to configure multiple backends in tripleo. Cheers, Oliver Von meinem iPhone gesendet > Am 03.11.2020 um 16:20 schrieb Tom Barron : > > On 01/11/20 08:55 +0100, Oliver Weinmann wrote: >> Hi, >> >> I'm still in the process of preparing a OpenStack POC. I'm 100% sure that I want to use CEPH and so I purchased the book Mastering CEPH 2nd edition. First of all, It's a really good book. It basically explains the various methods how ceph can be deployed and also the components that CEPH is build of. So I played around a lot with ceph-ansible and rook in my virtualbox environment. I also started to play with tripleo ceph deployment, although I haven't had the time yet to sucessfully deploy a openstack cluster with CEPH. Now I'm wondering, which of these 3 methods should I use? >> >> rook >> >> ceph-ansible >> >> tripleo >> >> I also want to use CEPH for NFS and CIFS (Samba) as we have plenty of VMs running under vSphere that currently consume storage from a ZFS storage via CIFS and NFS. I don't know if rook can be used for this. I have the feeling that it is purely meant to be used for kubernetes? And If I would like to have CIFS and NFS maybe tripleo is not capable of enabling these features in CEPH? So I would be left with ceph-ansible? >> >> Any suggestions are very welcome. >> >> Best Regards, >> >> Oliver >> >> > > If your core use case is OpenStack (OpenStack POC with CEPH) then of the three tools mentioned only tripleo will deploy OpenStack. It can deploy a Ceph cluster for use by OpenStack as well, or you can deploy Ceph externally and it will "point" to it from OpenStack. For an OpenStack POC (and maybe for production too) I'd just have TripleO deploy the Ceph cluster as well. TripleO will use a Ceph deployment tool -- today, ceph-ansible; in the future, cephadm -- to do the actual Ceph cluster deployment but it figures out how to run the Ceph deployment for you. > > I don't think any of these tools will install a Samba/CIFs gateway to CephFS. It's reportedly on the road map for the new cephadm tool. You may be able to manually retrofit it to your Ceph cluster by consulting upstream guidance such as [1]. > > NFS shares provisioned in OpenStack (Manila file service) *could* be shared out-of-cloud to VSphere VMs if networking is set up to make them accessible but the shares would remain OpenStack managed. To use the same Ceph cluster for OpenStack and vSphere but have separate storage pools behind them, and independent management, you'd need to deploy the Ceph cluster independently of OpenStack and vSphere. TripleO could "point" to this cluster as mentioned previously. > > I agree with your assessment that rook is intended to provide PVs for Kubernetes consumers. You didn't mention Kubernetes as a use case, but as John Fulton has mentioned it is possible to use rook on Kubernetes in a mode where it "points" to an external ceph cluster rather than provisioning its own as well. Or if you run k8s clusters on OpenStack, they can just consume the OpenStack storage, which will be Ceph storage when that is used to back OpenStack Cinder and Manila. > > -- Tom Barron > > [1] https://www.youtube.com/watch?v=5v8L7FhIyOw&list=PLrBUGiINAakNCnQUosh63LpHbf84vegNu&index=19&t=0s&app=desktop > From dmendiza at redhat.com Tue Nov 3 21:35:44 2020 From: dmendiza at redhat.com (Douglas Mendizabal) Date: Tue, 3 Nov 2020 15:35:44 -0600 Subject: [barbican] Stable Branch Liaison Update Message-ID: <5ecc1230-b3e1-bf23-3a37-2c05f0b50f8d@redhat.com> Hi openstack-discuss, I've updated the Cross Project Liaison Wiki [1] to revert our Stable Branch liaison to myself as current Barbican PTL. I am wondering what the process is to get myself added to the barbican-stable-maint group in gerrit? [2] Unfortunately, our only team member on that team has not been very active the last few months and we have a growing list of patches to the stable branches that we have been unable to merge. Any pointers would be greatly appreciated. Thanks - Douglas Mendizábal [1] https://wiki.openstack.org/wiki/CrossProjectLiaisons#Stable_Branch [2] https://review.opendev.org/#/admin/groups/1097 -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xF2294C99E916A3FB.asc Type: application/pgp-keys Size: 36788 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From sean.mcginnis at gmx.com Tue Nov 3 22:03:08 2020 From: sean.mcginnis at gmx.com (Sean McGinnis) Date: Tue, 3 Nov 2020 16:03:08 -0600 Subject: [barbican] Stable Branch Liaison Update In-Reply-To: <5ecc1230-b3e1-bf23-3a37-2c05f0b50f8d@redhat.com> References: <5ecc1230-b3e1-bf23-3a37-2c05f0b50f8d@redhat.com> Message-ID: > I am wondering what the process is to get myself added to the > barbican-stable-maint group in gerrit? [2] > > Unfortunately, our only team member on that team has not been very > active the last few months and we have a growing list of patches to the > stable branches that we have been unable to merge. > > Any pointers would be greatly appreciated. > > Thanks > - Douglas Mendizábal We usually just want to see that you have been doing stable reviews and show an understanding of the differences with things to look for when reviewing those rather than reviews on master. I took a look at some and they looked fine to me. Obligatory reminder though to read through the stable branch policies, particularly the review guidelines: https://docs.openstack.org/project-team-guide/stable-branches.html#review-guidelines I have added you to the barbican-stable-maint group. Please raise any questions if you have any doubts about any proposed changes. Thanks! Sean From rosmaita.fossdev at gmail.com Wed Nov 4 01:08:47 2020 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Tue, 3 Nov 2020 20:08:47 -0500 Subject: [cinder] Wallaby PTG summary available Message-ID: I've posted a summary of the discussions we had last week: https://wiki.openstack.org/wiki/CinderWallabyPTGSummary Feel free to make any corrections or clarifications. Also, look through to remind yourself what actions you volunteered to perform (you can search for your IRC nick or the text ACTION). cheers, brian From satish.txt at gmail.com Wed Nov 4 02:51:10 2020 From: satish.txt at gmail.com (Satish Patel) Date: Tue, 3 Nov 2020 21:51:10 -0500 Subject: Intel 82599 dpdk support with centos8 Message-ID: Folks, I am trying to get dpdk working with my OVS on CentOS-8 and I am stuck here so I need advice from folks who can help me here. I have an HP c7000 chassis with ProLiant BL460c Gen9 blade. I am running CentOS-8 with following version of ovs-dpdk [root at compute-2 usertools]# ovs-vswitchd --version ovs-vswitchd (Open vSwitch) 2.12.0 DPDK 18.11.2 I am using openstack-ansible to set up openvswitch with dpdk, and so far everything went well but I am stuck in the end. [root at compute-2 usertools]# ovs-vsctl add-port br-provider dpdk-0 -- set Interface dpdk-0 type=dpdk options:dpdk-devargs=0000:06:00.0 ovs-vsctl: Error detected while setting up 'dpdk-0': Error attaching device '0000:06:00.0' to DPDK. See ovs-vswitchd log for details. ovs-vsctl: The default log directory is "/var/log/openvswitch". Here is the error message. [root at compute-2 usertools]# tail -f /var/log/openvswitch/ovs-vswitchd.log 2020-11-04T02:46:31.751Z|00303|dpdk|INFO|EAL: PCI device 0000:06:00.0 on NUMA socket 0 2020-11-04T02:46:31.751Z|00304|dpdk|INFO|EAL: probe driver: 8086:10f8 net_ixgbe 2020-11-04T02:46:31.751Z|00305|dpdk|ERR|EAL: Driver cannot attach the device (0000:06:00.0) 2020-11-04T02:46:31.751Z|00306|dpdk|ERR|EAL: Failed to attach device on primary process 2020-11-04T02:46:31.751Z|00307|netdev_dpdk|WARN|Error attaching device '0000:06:00.0' to DPDK 2020-11-04T02:46:31.751Z|00308|netdev|WARN|dpdk-0: could not set configuration (Invalid argument) 2020-11-04T02:46:31.751Z|00309|dpdk|ERR|Invalid port_id=32 This is what my NIC firmware/driver [root at compute-2 usertools]# ethtool -i eno50 driver: ixgbe version: 5.1.0-k-rh8.2.0 firmware-version: 0x800008fb, 1.2028.0 expansion-rom-version: bus-info: 0000:06:00.1 [root at compute-2 usertools]# python3 ./dpdk-devbind.py --status Network devices using DPDK-compatible driver ============================================ 0000:06:00.0 '82599 10 Gigabit Dual Port Backplane Connection 10f8' drv=vfio-pci unused=ixgbe Network devices using kernel driver =================================== 0000:06:00.1 '82599 10 Gigabit Dual Port Backplane Connection 10f8' if=eno50 drv=ixgbe unused=vfio-pci I did enabled IOMMU & huge mem in grub iommu=pt intel_iommu=on hugepagesz=2M hugepages=30000 transparent_hugepage=never Not sure what is wrong here and the big question is does this NIC support DPDK or not? From dsneddon at redhat.com Wed Nov 4 06:13:40 2020 From: dsneddon at redhat.com (Dan Sneddon) Date: Tue, 3 Nov 2020 22:13:40 -0800 Subject: [rhos-dev] [Neutron] PTG summary In-Reply-To: <6315331.olFIrCdlcp@p1> References: <6315331.olFIrCdlcp@p1> Message-ID: <9a4115a0-5fec-7342-daf6-82478b65799e@redhat.com> On 11/2/20 1:56 PM, Slawek Kaplonski wrote: > Hi, > > Below is my summary of the Neutron team sessions which we had during the > virtual PTG last week. > Etherpad with notes from the discussions can be found at [1]. > > ## Retrospective of the Victoria cycle >>From the good things during _Victoria_ cycle team pointed: > * Complete 8 blueprints including the _Metadata over IPv6_ [2], > * Improved feature parity in the OVN driver, > * Good review velocity > >>From the not so good things we mentioned: > * CI instability - average number of rechecks needed to merge patch in last > year can be found at [3], > * Too much "Red Hat" in the Neutron team - and percentage of the reviews (and > patches) done by people from Red Hat is constantly increasing over last few > cycles. As a main reason of that we pointed that it is hard to change > companies way of thinking that dedicating developer to the upstream project > means that they lose developer in downstream. > * Migration of our CI and Zuul v3 took us a lot of time and effort - but good > thing is that we accomplished that in the Victoria cycle :) > > During that session we also agreed on some action items for the Wallaby cycle: > * keep talking about OVN details - Miguel Lavalle and me will work on some way > to deliver talks about Neutron OVN backend and OVN internals to the community > during next months. The idea is to maybe propose some talks ever 6 weeks or > so. This may make ovn driver development more diverse and let operators to > thing about migration to the ovn backend. > > ## Review of the existing meetings > We reviewed list of our existing upstream meetings and discussed about ideas > on how to increase number of attendees on the meetings. > We decided to: > * drop neutron-qos meeting as it's not needed anymore > * advertise more meetings and meetings' agenda on the OpenStack mailing list - > I will send reminders with links to the agenda before every meeting > * Together with Lajos Katona we will give some introduction to the debugging > of CI issues in Neutron* > > ## Support for old versions > Bernard started discussion about support for the old releases in Neutron and > Neutron stadium projects. > For Neutron we decided to mark __Ocata__ branch as unmaintained already as its > gate is already broken. > For the __Pike__ and never branches we will keep them in the __EM__ phase as > there is still some community interest to keep those branches open. > For the stadium projects we decided to do it similary to what we did while > looking for new maintainers for the projects. We will send email "call for > maintainers" for such stable branches. If there will be no voluneers to step > in, fix gate issues and keep those branches healthy, we will mark them as > __unmaintained__ and later as __End of Life__ (EOL). > Currently broken CI is in projects: > * networking-sfc, > * networking-bgpvpn/bagpipe, > * neutron-fwaas > > And those are candidates to be marked as unmaintained if there will be no > volunteers to fix them. > Bernard Cafarelli volunteered to work on that in next days/weeks. > > > ## Healtcheck API endpoint > We discussed as our healtcheck API should works. During the discussion we > decided that: > * healtcheck result should __NOT__ rely on the agents status, it should rely > on worker's ability to connect to the DB and MQ (rabbitmq) > * Lajos will ask community (API experts) about some guidance how it should > works on the whole OpenStack level, > * As for reference implementation we can check e.g. Octavia [4] and Keystone > [5] which already implemented it. > > ## Squash of the DB migration script > Rodolfo explained us what are benefits of doing such squash of the db migration > scripts from the old versions: > * Deployment is faster: we don't need to create/delete tables or create+update > other ones - the win is small possibly in the magnitude of 5s per job, > * DB definition is centralized in one place, not in original definition plus > further migrations - that is most important reason why we really should do > that, > * UTs faster: removal of some older checks. > > The problem with this may be that we need to do that carefully and be really > verbose about with such changes we may break stadium projects or 3rd party > projects which are doing db migration too. > To minimalize potential breakage, we will announce such changes on the > OpenStack discuss mailing list. > Rodolfo volunteered to take propose squash up to Liberty release in W cycle. > Together with this squash we will also document that process so in next cycles > we should be able to do squashes for newer releases in easier way. > Lajos volunteered to help with fixing Neutron stadium projects if that will be > needed. > > ## Switch to the new engine facade > We were discussing how to move on and finally finish old Blueprint [6]. We > decided that together with Rodolfo we will try how this new engine facade will > work without using transaction guards in the code. Hopefully that will let us > move on with this. If not, we will try to reach out to some DB experts for > some help with this. > > ## Change from rootwrap to the privsep > This is now community goal during the Wallaby cycle so we need to focus on it > to accomplish that transition finally. > This transition may speed up and make our code a bit more secure. > Rodolfo explained us multiple possible strategies of migration: > * move to native, e.g. > * replace ps with python psutils, not using rootwrap or privsep > * replace ip commands with pyroute2, under a privsep context (elevated > permissions needed) > * directly translate rootwrap to privsep, executing the same shell command but > under a privsep context > > To move on with this I will create list of the pieces of code which needs to > be transitioned in the Neutron repo and in the stadium projects. > Current todo items can be found on the storyboard [7]. > > ## Migration to the NFtables > During this session we were discussing potential strategies on how to migrate > from the old iptables to the new nftables. We need to start planning that work > as it major Linux distributions (e.g. RHEL) are planning to deprecate iptables > in next releases. > It seems that currently all major distros (Ubuntu, Centos, OpenSuSE) supports > nftables already. > We decided that in Wallaby cycle we will propose new _Manager_ class and we > will add some config option which will allow people to test new solution. > In next cycles we will continue work on it to make it stable and to make > upgrade and migration path for users as easy as possible. > There is already created blueprint to track progress on that topic [8]. > We need to migrate: > * Linuxbridge firewall, iptables OVS hybrid firewall, > * L3 code (legacy router, DVR router, conntrack, port forwarding), > * iptables metering, > * metadata proxy, > * dhcp agent for when it does metadata for isolated networks and namespace > creation, > * neutron-vpnaas - ipsec code, > * and maybe something else what we didn't found yet. > > ## Nova-Neutron cross project session > We had very interesting discussion with Nova team. We were discussing topics > like: > * NUMA affinity in the neutron port > * vhost-vdpa support > * default __vnic_type__/__port flavour__ > > Notes from that discussion are available in the nova's etherpad [9]. > > ## Neutron scalling issues > At this session we were discussing issues mentioned by operators on the Forum > sessions a week before the PTG. There was couple of issues mentioned there: > * problems with retries of the DB operations - we should migrate all our code > to the oslo.db retries mechanism - new blueprint [10] is created to track > progress on that one. > * problems with maintenance of the agents, like e.g. DHCP or L3 agents - many > of those issues are caused by how our agents are designed and to really fix > that we would need very deep and huge changes. But also many of those issues > can be solved by the __ovn__ backend - **and that is strategic direction in > which neutron wants to go in the next cycles**, > * Miguel Lavalle and I volunteered to do some profiling of the agents to see > where we are loosing most of the time - maybe we will be able to find some _low > hanging fruits_ which can be fixed and improve the situation at least a bit, > * Similar problem with neutron-ovs-agent and especially security groups which > are using _remove group id_ as a reference - here we also need some volunteers > who will try to optimize that. > > ## CI (in)stablility > On Thursday we were discussing how to improve our very poor CI. Finally we > decided to: > * not recheck patches without giving reason of recheck in the comment - there > should be already reported bug which should be linked in the _recheck_ > comment, or user should open new one and link to it also. IN case if the > problem was e.g. related to infra some simple comment like _infra issue_ will > also be enough there, > * To lower number of existing jobs we will do some changes like: > * move *-neutron-lib-master and *-ovs-master jobs to the experimental and > periodic queues to not run them on every patch, > * I will switch _neutron-tempest-plugin-api_ job to be deployed with uwsgi > so we can drop _neutron-tempest-with-uwsgi_ job, > * Consolidate _neutron-tempest-plugin-scenario-linuxbridge_ and _neutron- > tempest-linuxbridge_ jobs, > * Consolidate _neutron-tempest-plugin-scenario-iptables_hybrid and _neutron- > tempest-iptables_hybrid jobs, > > Later we also discussed about the way how to run or skip tests which can be > only run when some specific feature is available in the cloud (e.g. _Metadata > over IPv6_). After some discussion we decided to add new config option with > list of enabled features. It will be very similar to the existing option > _api_extensions_. Lajos volunteered to work on that. > > As last CI related topic we discussed about testing DVR in our CI. Oleg > Bondarev volunteered to check and try to fix broken _neutron-tempest-plugin- > dvr-multinode-scenario_ job. > > ## Flow based DHCP > > Liu Yulong raised topic about new way of doing fully distributed DHCP service, > instead of using _DHCP agent_ on the nodes - RFE is proposed at [11]. His > proposal of doing Open Flow based DHCP (similar to what e.g. ovn-controller is > doing) is described in [12]. It could be implemented as an L2 agent extension > and enabled by operators in the config when they would need it. > As a next step Liu will now propose spec with details about this solution and > we will continue discussion about it in the spec's review. When retiring the DHCP agent was discussed in Shanghai it was assumed that the flow-based DHCP server would not be compatible with Ironic. Currently the OVN native implementation is not compatible and DHCP agent is required, but OVN is planning on implementing support for native DHCP for Ironic soon (IIUC). Was there any discussion about what it might take to extend the flow-based DHCP server to support direct connection to VLAN/flat networks and the DHCP options required for PXE/iPXE for Ironic? Is that a possibility in the future, or would we need to continue to maintain the DHCP agent even if OVN no longer requires it? > > ## Routed provider networks limited to one host > > As a lost topic on Thursday we briefly talked about old RFE [13]. Miguel > Lavalle told us that his company, Verizon Media, is interested in working on > this RFE in next cycles. This also involves some work on Nova's side which was > started by Sylvain Bauza already. Miguel will sync with Sylvain on that RFE. > > ## L3 feature improvements > > On Friday we were discussing some potential improvements in the L3 area. Lajos > and Bence shown us some features which their company is interested in and on > which they plan to work. Those are things like: > * support for Bidirectional Forwarding Detection > * some additional API to set additional router parameters like: > * ECMP max path, > * ECMP hash algorith > * --provider-allocation-pool parameter in the subnets - in some specific cases > it may help to use IPs from such _special_ pool for some infrastructure needs, > more details about that will come in the RFE in future, > For now all those described above improvements are in very early planning > phase but Bence will sync with Liu and Liu will dedicate some time to discuss > progress on them during the __L3 subteam meetings__. I submitted a spec for installing FRRouting (FRR) via TripleO: https://review.opendev.org/#/c/758249/ This could be used for ECMP, as well as for routing traffic to the HAProxy load balancers fronting the control plane, and advertising routes to Neutron IPs on dynamically routed networks (VM IPs and/or floating IPs). The goal is to have a very simple implementation where IP addresses would be added to a default or alternate namespace (depending on the use case) as loopback addresses with a /32 (v4) or /128 (v6) CIDR. In the case of FRR the Zebra daemon receives updates via Netlink when these IP addresses are created locally and redistributes them to BGP peers. In theory this may allow a different BGP daemon such as Bird or perhaps ExaBGP to be easily swapped for FRR. I will look forward to seeing more on the --provider-allocation-pool parameter. > > ## Leveraging routing-on-the-host in Neutron in our next-gen clusters > > As a last topic on Friday we were discussing potential solutions of the _L3 on > the host_ in the Neutron. The idea here is very similar to what e.g. __Calico > plugin__ is doing currently. > More details about potential solutions are described in the etherpad [14]. > During the discussion Dawid Deja from OVH told us that OVH is also using very > similar, downstream only solution. > Conclusion of that discussion was that we may have most of the needed code > already in Neutron and some stadium projects so as a first step people who are > interested in that topic, like Jan Gutter, Miguel and Dawid will work on some > deployment guide for such use case. Is there any public info on the OVH approach available? > > ## Team photo > During the PTG we also made team photos which You can find at [15]. > > [1] https://etherpad.opendev.org/p/neutron-wallaby-ptg > [2] https://blueprints.launchpad.net/neutron/+spec/metadata-over-ipv6 > [3] https://ibb.co/12sB9N9 > [4] https://opendev.org/openstack/octavia/src/branch/master/octavia/api/ > healthcheck/healthcheck_plugins.py > [5] https://docs.openstack.org/keystone/victoria/admin/health-check-middleware.html > [6] https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch > [7] https://storyboard.openstack.org/#!/story/2007686 > [8] https://blueprints.launchpad.net/neutron/+spec/nftables-migration > [9] https://etherpad.opendev.org/p/nova-wallaby-ptg > [10] https://blueprints.launchpad.net/neutron/+spec/oslo-db-retries > [11] https://bugs.launchpad.net/neutron/+bug/1900934 > [12] https://github.com/gotostack/shanghai_ptg/blob/master/ > shanghai_neutron_ptg_topics_liuyulong.pdf > [13] https://bugs.launchpad.net/neutron/+bug/1764738 > [14] https://etherpad.opendev.org/p/neutron-routing-on-the-host > [15] http://kaplonski.pl/files/Neutron_virtual_PTG_October_2020.tar.gz > -- Dan Sneddon | Senior Principal Software Engineer dsneddon at redhat.com | redhat.com/cloud dsneddon:irc | @dxs:twitter From skaplons at redhat.com Wed Nov 4 08:35:57 2020 From: skaplons at redhat.com (Slawek Kaplonski) Date: Wed, 04 Nov 2020 09:35:57 +0100 Subject: [rhos-dev] [Neutron] PTG summary In-Reply-To: <9a4115a0-5fec-7342-daf6-82478b65799e@redhat.com> References: <6315331.olFIrCdlcp@p1> <9a4115a0-5fec-7342-daf6-82478b65799e@redhat.com> Message-ID: <1955767.2ncHDK62ns@p1> Hi, Dnia środa, 4 listopada 2020 07:13:40 CET Dan Sneddon pisze: > On 11/2/20 1:56 PM, Slawek Kaplonski wrote: > > Hi, > > > > Below is my summary of the Neutron team sessions which we had during the > > virtual PTG last week. > > Etherpad with notes from the discussions can be found at [1]. > > > > ## Retrospective of the Victoria cycle > > > >>From the good things during _Victoria_ cycle team pointed: > > * Complete 8 blueprints including the _Metadata over IPv6_ [2], > > * Improved feature parity in the OVN driver, > > * Good review velocity > > > >>From the not so good things we mentioned: > > * CI instability - average number of rechecks needed to merge patch in > > last > > year can be found at [3], > > * Too much "Red Hat" in the Neutron team - and percentage of the reviews > > (and patches) done by people from Red Hat is constantly increasing over > > last few cycles. As a main reason of that we pointed that it is hard to > > change companies way of thinking that dedicating developer to the > > upstream project means that they lose developer in downstream. > > * Migration of our CI and Zuul v3 took us a lot of time and effort - but > > good thing is that we accomplished that in the Victoria cycle :) > > > > During that session we also agreed on some action items for the Wallaby > > cycle: * keep talking about OVN details - Miguel Lavalle and me will work > > on some way to deliver talks about Neutron OVN backend and OVN internals > > to the community during next months. The idea is to maybe propose some > > talks ever 6 weeks or so. This may make ovn driver development more > > diverse and let operators to thing about migration to the ovn backend. > > > > ## Review of the existing meetings > > We reviewed list of our existing upstream meetings and discussed about > > ideas on how to increase number of attendees on the meetings. > > We decided to: > > * drop neutron-qos meeting as it's not needed anymore > > * advertise more meetings and meetings' agenda on the OpenStack mailing > > list - I will send reminders with links to the agenda before every > > meeting * Together with Lajos Katona we will give some introduction to > > the debugging of CI issues in Neutron* > > > > ## Support for old versions > > Bernard started discussion about support for the old releases in Neutron > > and Neutron stadium projects. > > For Neutron we decided to mark __Ocata__ branch as unmaintained already as > > its gate is already broken. > > For the __Pike__ and never branches we will keep them in the __EM__ phase > > as there is still some community interest to keep those branches open. > > For the stadium projects we decided to do it similary to what we did > > while looking for new maintainers for the projects. We will send email > > "call for maintainers" for such stable branches. If there will be no > > voluneers to step in, fix gate issues and keep those branches healthy, we > > will mark them as __unmaintained__ and later as __End of Life__ (EOL). > > Currently broken CI is in projects: > > * networking-sfc, > > * networking-bgpvpn/bagpipe, > > * neutron-fwaas > > > > And those are candidates to be marked as unmaintained if there will be no > > volunteers to fix them. > > Bernard Cafarelli volunteered to work on that in next days/weeks. > > > > > > ## Healtcheck API endpoint > > We discussed as our healtcheck API should works. During the discussion we > > decided that: > > * healtcheck result should __NOT__ rely on the agents status, it should > > rely on worker's ability to connect to the DB and MQ (rabbitmq) > > * Lajos will ask community (API experts) about some guidance how it should > > works on the whole OpenStack level, > > * As for reference implementation we can check e.g. Octavia [4] and > > Keystone [5] which already implemented it. > > > > ## Squash of the DB migration script > > Rodolfo explained us what are benefits of doing such squash of the db > > migration scripts from the old versions: > > * Deployment is faster: we don't need to create/delete tables or > > create+update other ones - the win is small possibly in the magnitude of > > 5s per job, * DB definition is centralized in one place, not in original > > definition plus further migrations - that is most important reason why we > > really should do that, > > * UTs faster: removal of some older checks. > > > > The problem with this may be that we need to do that carefully and be > > really verbose about with such changes we may break stadium projects or > > 3rd party projects which are doing db migration too. > > To minimalize potential breakage, we will announce such changes on the > > OpenStack discuss mailing list. > > Rodolfo volunteered to take propose squash up to Liberty release in W > > cycle. Together with this squash we will also document that process so in > > next cycles we should be able to do squashes for newer releases in easier > > way. Lajos volunteered to help with fixing Neutron stadium projects if > > that will be needed. > > > > ## Switch to the new engine facade > > We were discussing how to move on and finally finish old Blueprint [6]. We > > decided that together with Rodolfo we will try how this new engine facade > > will work without using transaction guards in the code. Hopefully that > > will let us move on with this. If not, we will try to reach out to some > > DB experts for some help with this. > > > > ## Change from rootwrap to the privsep > > This is now community goal during the Wallaby cycle so we need to focus on > > it to accomplish that transition finally. > > This transition may speed up and make our code a bit more secure. > > Rodolfo explained us multiple possible strategies of migration: > > * move to native, e.g. > > > > * replace ps with python psutils, not using rootwrap or privsep > > * replace ip commands with pyroute2, under a privsep context (elevated > > > > permissions needed) > > * directly translate rootwrap to privsep, executing the same shell command > > but under a privsep context > > > > To move on with this I will create list of the pieces of code which needs > > to be transitioned in the Neutron repo and in the stadium projects. > > Current todo items can be found on the storyboard [7]. > > > > ## Migration to the NFtables > > During this session we were discussing potential strategies on how to > > migrate from the old iptables to the new nftables. We need to start > > planning that work as it major Linux distributions (e.g. RHEL) are > > planning to deprecate iptables in next releases. > > It seems that currently all major distros (Ubuntu, Centos, OpenSuSE) > > supports nftables already. > > We decided that in Wallaby cycle we will propose new _Manager_ class and > > we > > will add some config option which will allow people to test new solution. > > In next cycles we will continue work on it to make it stable and to make > > upgrade and migration path for users as easy as possible. > > There is already created blueprint to track progress on that topic [8]. > > We need to migrate: > > * Linuxbridge firewall, iptables OVS hybrid firewall, > > * L3 code (legacy router, DVR router, conntrack, port forwarding), > > * iptables metering, > > * metadata proxy, > > * dhcp agent for when it does metadata for isolated networks and namespace > > creation, > > * neutron-vpnaas - ipsec code, > > * and maybe something else what we didn't found yet. > > > > ## Nova-Neutron cross project session > > We had very interesting discussion with Nova team. We were discussing > > topics like: > > * NUMA affinity in the neutron port > > * vhost-vdpa support > > * default __vnic_type__/__port flavour__ > > > > Notes from that discussion are available in the nova's etherpad [9]. > > > > ## Neutron scalling issues > > At this session we were discussing issues mentioned by operators on the > > Forum sessions a week before the PTG. There was couple of issues > > mentioned there: * problems with retries of the DB operations - we should > > migrate all our code to the oslo.db retries mechanism - new blueprint > > [10] is created to track progress on that one. > > * problems with maintenance of the agents, like e.g. DHCP or L3 agents - > > many of those issues are caused by how our agents are designed and to > > really fix that we would need very deep and huge changes. But also many > > of those issues can be solved by the __ovn__ backend - **and that is > > strategic direction in which neutron wants to go in the next cycles**, > > * Miguel Lavalle and I volunteered to do some profiling of the agents to > > see where we are loosing most of the time - maybe we will be able to find > > some _low hanging fruits_ which can be fixed and improve the situation at > > least a bit, * Similar problem with neutron-ovs-agent and especially > > security groups which are using _remove group id_ as a reference - here > > we also need some volunteers who will try to optimize that. > > > > ## CI (in)stablility > > On Thursday we were discussing how to improve our very poor CI. Finally we > > decided to: > > * not recheck patches without giving reason of recheck in the comment - > > there should be already reported bug which should be linked in the > > _recheck_ comment, or user should open new one and link to it also. IN > > case if the problem was e.g. related to infra some simple comment like > > _infra issue_ will also be enough there, > > > > * To lower number of existing jobs we will do some changes like: > > * move *-neutron-lib-master and *-ovs-master jobs to the experimental > > and > > > > periodic queues to not run them on every patch, > > > > * I will switch _neutron-tempest-plugin-api_ job to be deployed with > > uwsgi > > > > so we can drop _neutron-tempest-with-uwsgi_ job, > > > > * Consolidate _neutron-tempest-plugin-scenario-linuxbridge_ and > > _neutron- > > > > tempest-linuxbridge_ jobs, > > > > * Consolidate _neutron-tempest-plugin-scenario-iptables_hybrid and > > _neutron-> > > tempest-iptables_hybrid jobs, > > > > Later we also discussed about the way how to run or skip tests which can > > be > > only run when some specific feature is available in the cloud (e.g. > > _Metadata over IPv6_). After some discussion we decided to add new config > > option with list of enabled features. It will be very similar to the > > existing option _api_extensions_. Lajos volunteered to work on that. > > > > As last CI related topic we discussed about testing DVR in our CI. Oleg > > Bondarev volunteered to check and try to fix broken > > _neutron-tempest-plugin- dvr-multinode-scenario_ job. > > > > ## Flow based DHCP > > > > Liu Yulong raised topic about new way of doing fully distributed DHCP > > service, instead of using _DHCP agent_ on the nodes - RFE is proposed at > > [11]. His proposal of doing Open Flow based DHCP (similar to what e.g. > > ovn-controller is doing) is described in [12]. It could be implemented as > > an L2 agent extension and enabled by operators in the config when they > > would need it. > > As a next step Liu will now propose spec with details about this solution > > and we will continue discussion about it in the spec's review. > > When retiring the DHCP agent was discussed in Shanghai it was assumed > that the flow-based DHCP server would not be compatible with Ironic. > Currently the OVN native implementation is not compatible and DHCP agent > is required, but OVN is planning on implementing support for native DHCP > for Ironic soon (IIUC). > > Was there any discussion about what it might take to extend the > flow-based DHCP server to support direct connection to VLAN/flat > networks and the DHCP options required for PXE/iPXE for Ironic? Is that > a possibility in the future, or would we need to continue to maintain > the DHCP agent even if OVN no longer requires it? For now we didn't discuss that. And we also don't have plans to drop support for DHCP agent. This new proposal is for sure not good for every usecase and will be (at least for now) proposed as an alternative solution which can be used if features like e.g. dns name resolutions are not needed. In the future we can of course thing about extending this new solution to something more complete. > > > ## Routed provider networks limited to one host > > > > As a lost topic on Thursday we briefly talked about old RFE [13]. Miguel > > Lavalle told us that his company, Verizon Media, is interested in working > > on this RFE in next cycles. This also involves some work on Nova's side > > which was started by Sylvain Bauza already. Miguel will sync with Sylvain > > on that RFE. > > > > ## L3 feature improvements > > > > On Friday we were discussing some potential improvements in the L3 area. > > Lajos and Bence shown us some features which their company is interested > > in and on which they plan to work. Those are things like: > > * support for Bidirectional Forwarding Detection > > > > * some additional API to set additional router parameters like: > > * ECMP max path, > > * ECMP hash algorith > > > > * --provider-allocation-pool parameter in the subnets - in some specific > > cases it may help to use IPs from such _special_ pool for some > > infrastructure needs, more details about that will come in the RFE in > > future, > > For now all those described above improvements are in very early planning > > phase but Bence will sync with Liu and Liu will dedicate some time to > > discuss progress on them during the __L3 subteam meetings__. > > I submitted a spec for installing FRRouting (FRR) via TripleO: > > https://review.opendev.org/#/c/758249/ > > This could be used for ECMP, as well as for routing traffic to the > HAProxy load balancers fronting the control plane, and advertising > routes to Neutron IPs on dynamically routed networks (VM IPs and/or > floating IPs). > > The goal is to have a very simple implementation where IP addresses > would be added to a default or alternate namespace (depending on the use > case) as loopback addresses with a /32 (v4) or /128 (v6) CIDR. In the > case of FRR the Zebra daemon receives updates via Netlink when these IP > addresses are created locally and redistributes them to BGP peers. In > theory this may allow a different BGP daemon such as Bird or perhaps > ExaBGP to be easily swapped for FRR. Thx for the info on that. I sent it to Miguel Lavalle and Jan Gutter who were mostly interested in that work in upstream. > > I will look forward to seeing more on the --provider-allocation-pool > parameter. > > > ## Leveraging routing-on-the-host in Neutron in our next-gen clusters > > > > As a last topic on Friday we were discussing potential solutions of the > > _L3 on the host_ in the Neutron. The idea here is very similar to what > > e.g. __Calico plugin__ is doing currently. > > More details about potential solutions are described in the etherpad [14]. > > During the discussion Dawid Deja from OVH told us that OVH is also using > > very similar, downstream only solution. > > Conclusion of that discussion was that we may have most of the needed code > > already in Neutron and some stadium projects so as a first step people who > > are interested in that topic, like Jan Gutter, Miguel and Dawid will work > > on some deployment guide for such use case. > > Is there any public info on the OVH approach available? I don't think so but I can try to explain it to You more or less if You want as I was original co-author of that solution many years ago. Please ping me off the list if You are interested :) > > > ## Team photo > > During the PTG we also made team photos which You can find at [15]. > > > > [1] https://etherpad.opendev.org/p/neutron-wallaby-ptg > > [2] https://blueprints.launchpad.net/neutron/+spec/metadata-over-ipv6 > > [3] https://ibb.co/12sB9N9 > > [4] https://opendev.org/openstack/octavia/src/branch/master/octavia/api/ > > healthcheck/healthcheck_plugins.py > > [5] > > https://docs.openstack.org/keystone/victoria/admin/health-check-middlewar > > e.html [6] > > https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch [7] > > https://storyboard.openstack.org/#!/story/2007686 > > [8] https://blueprints.launchpad.net/neutron/+spec/nftables-migration > > [9] https://etherpad.opendev.org/p/nova-wallaby-ptg > > [10] https://blueprints.launchpad.net/neutron/+spec/oslo-db-retries > > [11] https://bugs.launchpad.net/neutron/+bug/1900934 > > [12] https://github.com/gotostack/shanghai_ptg/blob/master/ > > shanghai_neutron_ptg_topics_liuyulong.pdf > > [13] https://bugs.launchpad.net/neutron/+bug/1764738 > > [14] https://etherpad.opendev.org/p/neutron-routing-on-the-host > > [15] http://kaplonski.pl/files/Neutron_virtual_PTG_October_2020.tar.gz > > -- > Dan Sneddon | Senior Principal Software Engineer > dsneddon at redhat.com | redhat.com/cloud > dsneddon:irc | @dxs:twitter -- Slawek Kaplonski Principal Software Engineer Red Hat From skaplons at redhat.com Wed Nov 4 08:46:42 2020 From: skaplons at redhat.com (Slawek Kaplonski) Date: Wed, 04 Nov 2020 09:46:42 +0100 Subject: [Neutron] PTG summary In-Reply-To: <16c52015-e038-317b-27b7-4831987efa1b@debian.org> References: <6315331.olFIrCdlcp@p1> <16c52015-e038-317b-27b7-4831987efa1b@debian.org> Message-ID: <1946063.3LDORFbjrG@p1> Hi, Dnia poniedziałek, 2 listopada 2020 23:59:58 CET Thomas Goirand pisze: > Hi Slawek, > > Thanks a lot for the summary, that's very useful. > > On 11/2/20 10:56 PM, Slawek Kaplonski wrote: > > * replace ip commands with pyroute2, under a privsep context (elevated > > > > permissions needed) > > Please, please, please, do this, and give it some high priority. > Spawning thousands of times the ip command simply doesn't scale. Yes, we know that :) And it's one of our priorities in this cycle. > > > ## Migration to the NFtables > > During this session we were discussing potential strategies on how to > > migrate from the old iptables to the new nftables. We need to start > > planning that work as it major Linux distributions (e.g. RHEL) are > > planning to deprecate iptables in next releases. > > Did you know that Debian uses nftables by default since Buster, and that > one must set iptables-legacy as alternative, otherwise Neutron becomes > mad and fails applying firewall rules? Yes, that work already has been started - see https://review.opendev.org/#/c/ 759874/ But it's a lot of work to do so it may not be very fast and help is welcome in that area :) > > I'm not sure about Bullseye, but maybe there, iptables-legacy will even > be gone?!? > > > ## Leveraging routing-on-the-host in Neutron in our next-gen clusters > > > > As a last topic on Friday we were discussing potential solutions of the > > _L3 on the host_ in the Neutron. The idea here is very similar to what > > e.g. __Calico plugin__ is doing currently. > > More details about potential solutions are described in the etherpad [14]. > > During the discussion Dawid Deja from OVH told us that OVH is also using > > very similar, downstream only solution. > > Conclusion of that discussion was that we may have most of the needed code > > already in Neutron and some stadium projects so as a first step people who > > are interested in that topic, like Jan Gutter, Miguel and Dawid will work > > on some deployment guide for such use case. > > It'd be great if people were sharing code for this. I've seen at least 3 > or 4 companies doing it, none sharing any bits... :/ Yes, I think that OVH may consider that. And also there should be now some collaboration betweem Jan, Miguel and maybe others on that topic. > > How well is the Calico plugin working for this? Do we know? Has anyone > tried it in production? Does it scale well? > > Cheers, > > Thomas Goirand (zigo) -- Slawek Kaplonski Principal Software Engineer Red Hat From Aija.Jaunteva at dell.com Wed Nov 4 09:35:19 2020 From: Aija.Jaunteva at dell.com (Jaunteva, Aija) Date: Wed, 4 Nov 2020 09:35:19 +0000 Subject: [ironic] Configuration mold follow-up In-Reply-To: References: Message-ID: Hi Dmitry, I don't see this to be the case. They need to be stored somewhere at the very beginning. This has been proposed to be a Wallaby priority and this meeting is necessary to move forward. Let's discuss this and other questions in the meeting. Regards, Aija From: Dmitry Tantsur Sent: Tuesday, November 3, 2020 18:41 To: openstack-discuss at lists.openstack.org Cc: Jaunteva, Aija Subject: Re: [ironic] Configuration mold follow-up [EXTERNAL EMAIL] Hi Aija, On Mon, Nov 2, 2020 at 1:55 PM Jaunteva, Aija > wrote: Hi, to follow up on Ironic PTG session about Configuration molds [1] I’m scheduling a call to discuss remaining items (mainly storage of the molds). Honestly, I feel like it's a bit premature to discuss the potential storage of the molds until we get the first version out and tested in the wild. Dmitry Anyone interested please add your availability in Doodle [2]. When time slot decided, will share call details. Regards, Aija [1] https://etherpad.opendev.org/p/ironic-wallaby-ptg line 216 [2] https://doodle.com/poll/dry4x5tbmhi6x6p3 -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtantsur at redhat.com Wed Nov 4 10:11:44 2020 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Wed, 4 Nov 2020 11:11:44 +0100 Subject: [ironic] Configuration mold follow-up In-Reply-To: References: Message-ID: Hi, On Wed, Nov 4, 2020 at 10:35 AM Jaunteva, Aija wrote: > Hi Dmitry, > > > > I don't see this to be the case. They need to be stored somewhere at the > very beginning. > Just pass the URLs in and out, no need to get fancy at this point. > This has been proposed to be a Wallaby priority and this meeting is > necessary to move forward. > > > > Let's discuss this and other questions in the meeting. > I'm not sure I'll have energy for yet another meeting, so please record my objection to adding an artefact storage API to ironic. Dmitry > > > Regards, > > Aija > > > > *From:* Dmitry Tantsur > *Sent:* Tuesday, November 3, 2020 18:41 > *To:* openstack-discuss at lists.openstack.org > *Cc:* Jaunteva, Aija > *Subject:* Re: [ironic] Configuration mold follow-up > > > > [EXTERNAL EMAIL] > > Hi Aija, > > > > On Mon, Nov 2, 2020 at 1:55 PM Jaunteva, Aija > wrote: > > Hi, > > > > to follow up on Ironic PTG session about Configuration molds [1] I’m > scheduling a call to discuss remaining items (mainly storage of the molds). > > > > Honestly, I feel like it's a bit premature to discuss the potential > storage of the molds until we get the first version out and tested in the > wild. > > > > Dmitry > > > > > > Anyone interested please add your availability in Doodle [2]. > > When time slot decided, will share call details. > > > > Regards, > > Aija > > > > [1] https://etherpad.opendev.org/p/ironic-wallaby-ptg line 216 > > [2] https://doodle.com/poll/dry4x5tbmhi6x6p3 > > > > -- > > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael > O'Neill > -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill -------------- next part -------------- An HTML attachment was scrubbed... URL: From themasch at gmx.net Wed Nov 4 10:36:09 2020 From: themasch at gmx.net (MaSch) Date: Wed, 4 Nov 2020 11:36:09 +0100 Subject: multiple nfs shares with cinder-backup Message-ID: Hello all! I'm currently using openstack queens with cinder 12.0.10. I would like to a backend I'm using a NFS-share. Now i would like to spit my backups up to two nfs-shares. I have seen that the cinder.volume.driver can handle multiple nfs shares. But it seems that cinder.backup.driver can not. Is there a way to use two nfs shares for backups? Or is it maybe possible with a later release of Cinder? regards, MaSch From thierry at openstack.org Wed Nov 4 11:31:42 2020 From: thierry at openstack.org (Thierry Carrez) Date: Wed, 4 Nov 2020 12:31:42 +0100 Subject: [largescale-sig] Future meeting time Message-ID: <580916f8-dd2e-fbca-56e4-b3ae0dfca85d@openstack.org> Hi everyone, During the PTG we discussed our meeting time. Currently we are rotating every two weeks between a APAC-EU friendly time (8utc) and a EU-US friendly time (16utc). However, rotating the meeting between two timezones resulted in fragmenting the already-small group, with only Europeans being regular attendees. After discussing this at the PTG with Gene Kuo, we think it's easier to have a single meeting time, if we can find one that works for all active members. Please enter your preferences into this date poll for Wednesday times: https://framadate.org/ue2eOBTT3QXoFhKg Feel free to add comments pointing to better times for you, like other days that would work better for you than Wednesdays for example. -- Thierry Carrez (ttx) From smooney at redhat.com Wed Nov 4 13:10:59 2020 From: smooney at redhat.com (Sean Mooney) Date: Wed, 04 Nov 2020 13:10:59 +0000 Subject: [nova] Why nova needs password-less SSH to do live migraiton? In-Reply-To: References: <9fb653f8-026d-d1de-8be6-6e7e39fca209@debian.org> , <2462c573-0a7a-8a27-b637-aadaba911580@debian.org> Message-ID: <8613e4169fce1123acf4faf5b687d696fa868505.camel@redhat.com> On Tue, 2020-11-03 at 11:15 +0000, Zhi CZ Chang wrote: > Alright, do you mean that the libvirtd daemon is started by the nova user? And the nova user has the same privilege as the root user? nova need ssh on live migration to do a few things. first is to test if the storage is shared. nova create a temp dir on the souce node then sshs to the dest node and checks if its visable. this is needed to determin if you mounted the instance state dir on nfs for example. the second reason is to copy some files that wont be copied by libvirt like vtpm data and in the past i think it also copied the config drive or console log. the third and most important usecase is establising the connection over which the qemu data is transfered. before libvirt/qemu supported native tls encryption of the transfered data ssh was the primary way to transfer the vm data in an encrypted form. the ssh tunnel was used to pipe the data form one qemu to another instead of using plain text tcp. in all 3 of these cases you only need to use the nova user not root. the nova user needs to be part of the libvit/qemu/kvm group depending on what OS you are on to manage vms but that also provides it with the requried permissions to live migrate the vm and update the instance state dir. root should not be needed and the nova user does not need full root permisions for live migration. >   > Thanks > Zhi Chang >   > > ----- Original message ----- > > From: Thomas Goirand > > To: "openstack-discuss at lists.openstack.org" > > Cc: > > Subject: [EXTERNAL] Re: [nova] Why nova needs password-less SSH to do live migraiton? > > Date: Tue, Nov 3, 2020 18:27 > >   > > On 11/3/20 9:18 AM, Zhi CZ Chang wrote: > > > Hi, Thomas > > >   > > > Thanks for your reply. > > >   > > > In your environment, you use the "root" user for authenticating with > > > each other compute node, rather than the "nova" user, right? > > > If so, why use the "root" user rather than the "nova" user then > > > privilege the root permission to the "nova" user? > > >   > > > Thanks > > > Zhi Chang > > > > Hi, > > > > No, the username is "nova", not "root". > > > > Thomas Goirand (zigo) > > > > P.S: Please don't CC me, I'm registered to the list. > >   >   > From ykarel at redhat.com Wed Nov 4 13:19:18 2020 From: ykarel at redhat.com (Yatin Karel) Date: Wed, 4 Nov 2020 18:49:18 +0530 Subject: [tripleo][ci] Monday Nov 2 In-Reply-To: References: <0b8e1c52-640d-9370-981d-c6db3814626c@redhat.com> Message-ID: Hi, On Tue, Nov 3, 2020 at 9:19 PM Marios Andreou wrote: > > > > On Tue, Nov 3, 2020 at 5:31 PM Wesley Hayutin wrote: >> >> >> >> On Tue, Nov 3, 2020 at 6:20 AM Bogdan Dobrelya wrote: >>> >>> On 10/30/20 6:31 PM, Wesley Hayutin wrote: >>> > Greetings, >>> > >>> > The tripleo ci team has identified a handful of patches that we'd like >>> > to land prior to Nov 2, the day docker.io goes away. >>> > We've hit some new bugs and have also tuned a few things to try and >>> > make sure we can get patches to merge. >>> > >>> > Our current focus is across master, victoria, ussuri and centos-8 train, >>> > and queens while reducing coverage in rocky and stein. >>> > >>> > A list of the prioritized gerrit reviews can be found here: >>> > https://hackmd.io/MlbZ_izSTEuZsCWTJvu_Kg?view >>> > >>> > The entire topic can be found here: >>> > https://review.opendev.org/#/q/topic:new-ci-job >>> >>> In that list there are patches to puppet modules and openstack services >>> what run a single standalone tripleo CI job. I don't think creating an >>> extra provider job to run a single consumer job sounds reasonable. >>> >>> > >>> > Thanks all. >> >> >> So our first pass there I think should be a content-provider. However we could potentially drop the content-provider and override docker.io -> quay.io as well. We are not certain yet how well quay.io will perform so we're being cautious atm. >> > > or as currently discussing with sshnaidm on irc the job itself can build the containers instead of having a content provider do that > > > 17:38 < sshnaidm|rover> maybe in puppet repos we will just build containers? > 17:38 < sshnaidm|rover> it's one standalone job there only, irrc > 17:38 < sshnaidm|rover> I think bogdan is right > 17:39 < marios> sshnaidm|rover: but is it worth it to special case that? in the end it is still just 'build one > set of containers' does it matter if it happens in a content provider or in the job itself? I > guess it depends how stable are the cotnent providers and the answer is 'not always' ... :/ > 17:40 < sshnaidm|rover> marios, it will remain one job there, not two > 17:40 < sshnaidm|rover> and no need to change layouts, just adding one variable > 17:40 < sshnaidm|rover> these repos anyway don't expect to run anything else from tripleo > 17:41 < sshnaidm|rover> ~10 repos * N branches, will save us a little work.. > 17:41 < marios> sshnaidm|rover: ack ... if it is easy enough to have that as special case then OK. and yes > having one job instead of 2 (one content provider) brings its own benefits > I raised it in https://review.opendev.org/#/c/760420 couple of days ago, just a note for standalone it should work fine but for other job like undercloud ones which also runs in some projects would need to add support for container-builds via build_container_images: true for those non provider jobs. >> >> >> >>> >>> >>> >>> -- >>> Best regards, >>> Bogdan Dobrelya, >>> Irc #bogdando >>> >>> Thanks and Regards Yatin Karel From hberaud at redhat.com Wed Nov 4 13:31:44 2020 From: hberaud at redhat.com (Herve Beraud) Date: Wed, 4 Nov 2020 14:31:44 +0100 Subject: [oslo][release] Oslo's Transition To Independent Message-ID: Greetings, Is it time for us to move some parts of Oslo to the independent release model [1]? I think we could consider Oslo world is mostly stable enough to answer yes to the previous question. However, the goal of this email is to trigger the debat and see which deliverables could be transitioned to the independent model. Do we need to expect that major changes will happen within Oslo and who could warrant to continue to follow cycle-with-intermediary model [2]? The following etherpad [3] is designed to help us to consider which deliverables could be moved. Concerning the roots of this topic, it was raised during the PTG of the Release Management Team [4]. [1] https://releases.openstack.org/reference/release_models.html#independent [2] https://releases.openstack.org/reference/release_models.html#cycle-with-intermediary [3] https://etherpad.opendev.org/p/oslo-transition-to-independent [4] https://etherpad.opendev.org/p/wallaby-ptg-os-relmgt /me takes off Oslo team hat and puts on release team hat. This kind of transition could be an option for all stable libraries even outside the Oslo scope, don't hesitate to consider this as an option for your projects. Thanks for reading, -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepa.kr at fingent.com Wed Nov 4 13:33:19 2020 From: deepa.kr at fingent.com (Deepa KR) Date: Wed, 4 Nov 2020 19:03:19 +0530 Subject: Random 503 error while running using api/command line Message-ID: Hi All Good Day We have a Train Openstack setup using juju maas configured in HA with 3 controllers. When using the openstack api getting a timeout error randomly. Also sometimes getting "Unknown Error (HTTP 503)" or Remote end closed connection without response while using the command line . openstack server list --all-projects *Unknown Error (HTTP 503)* Kindly suggest to look in the right direction. Regards, Deepa K R -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnaser at vexxhost.com Wed Nov 4 14:04:31 2020 From: mnaser at vexxhost.com (Mohammed Naser) Date: Wed, 4 Nov 2020 09:04:31 -0500 Subject: [tc] weeklu update Message-ID: 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. # Patches ## Open Reviews - Adding reno and warnings example for JSON->YAML goal doc https://review.opendev.org/760956 - Select JSON to YAML goal for Wallaby cycle https://review.opendev.org/760957 - Add goal for migrate RBAC policy format from JSON to YAML https://review.opendev.org/759881 - Add diablo_rojo liaison preferences https://review.opendev.org/759718 - Add danms liaison preferences https://review.opendev.org/758822 - Add ricolin liaison preferences https://review.opendev.org/759704 - Add gmann liaison preference https://review.opendev.org/758602 - Resetting projects' TC liaisons empty https://review.opendev.org/758600 - Move Placement under Nova's governance https://review.opendev.org/760917 - Clarify the requirements for supports-api-interoperability https://review.opendev.org/760562 - Add Resolution of TC stance on the OpenStackClient https://review.opendev.org/759904 ## General Changes - Implement distributed leadership in tools and schema https://review.opendev.org/757966 - Adding missing IRC nick https://review.opendev.org/759724 - Update dansmith IRC nick https://review.opendev.org/760561 - Update projects with Telemetry PTL election result https://review.opendev.org/760206 - Appoint XueFeng Liu as Senlin PTL https://review.opendev.org/758122 - Begin the 'X' release naming process https://review.opendev.org/759888 - Appoint Adam Harwell as Octavia PTL https://review.opendev.org/758121 - Add nomination for TC chair https://review.opendev.org/758181 - Appoint Rafael Weingartner as CloudKitty PTL https://review.opendev.org/758120 - Appoint Frode Nordahl as OpenStack Charms PTL https://review.opendev.org/758119 - Select Privsep as the Wallaby Goal https://review.opendev.org/755590 ## Project Updates - Adopting the DPL governance model for oslo https://review.opendev.org/757906 Thanks for reading! Mohammed -- Mohammed Naser VEXXHOST, Inc. From openstack at nemebean.com Wed Nov 4 14:49:57 2020 From: openstack at nemebean.com (Ben Nemec) Date: Wed, 4 Nov 2020 08:49:57 -0600 Subject: [oslo][release] Oslo's Transition To Independent In-Reply-To: References: Message-ID: <4a9dc3ba-ef77-fdfd-2729-b7cb6357e3ed@nemebean.com> On 11/4/20 7:31 AM, Herve Beraud wrote: > Greetings, > > Is it time for us to move some parts of Oslo to the independent release > model [1]? > > I think we could consider Oslo world is mostly stable enough to answer > yes to the previous question. > > However, the goal of this email is to trigger the debat and see which > deliverables could be transitioned to the independent model. > > Do we need to expect that major changes will happen within Oslo and who > could warrant to continue to follow cycle-with-intermediary model [2]? I would hesitate to try to predict the future on what will see major changes and what won't. I would prefer to look at this more from the perspective of what Oslo libraries are tied to the OpenStack version. For example, I don't think oslo.messaging should be moved to independent. It's important that RPC has a sane version to version upgrade path, and the easiest way to ensure that is to keep it on the regular cycle release schedule. The same goes for other libraries too: oslo.versionedobjects, oslo.policy, oslo.service, oslo.db, possibly also things like oslo.config and oslo.context (I suspect contexts need to be release-specific, but maybe someone from a consuming project can weigh in). Even oslo.serialization could have upgrade impacts if it is being used to serialize internal data in a service. That said, many of the others can probably be moved. oslo.i18n and oslo.upgradecheck are both pretty stable at this point and not really tied to a specific release. As long as we're responsible with any future changes to them it should be pretty safe to make them independent. This does raise a question though: Are the benefits of going independent with the release model sufficient to justify splitting the release models of the Oslo projects? I assume the motivation is to avoid having to do as many backports of bug fixes, but if we're mostly doing this with low-volume, stable projects does it gain us that much? I guess I don't have a strong opinion one way or another on this yet, and would defer to our release liaisons if they want to go one way or other other. Hopefully this provides some things to think about though. -Ben From rosmaita.fossdev at gmail.com Wed Nov 4 15:48:49 2020 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Wed, 4 Nov 2020 10:48:49 -0500 Subject: [cinder] Block Storage API v2 removal Message-ID: <8c96d38f-c14e-e246-d119-c83326555f45@gmail.com> The Block Storage API v2 was deprecated in the Pike release by Change-Id: I913c44799cddc37c3342729ec0ef34068db5b2d4 The Cinder team will be removing it during the Wallaby development cycle. At the Wallaby PTG, the question came up about Block Storage API v2 support in the python-cinderclient. We looked at some proposals [0] at today's Cinder meeting and plan to make a decision at next week's meeting [1]. If you have strong feelings about this issue, please make them known on the etherpad [0], the ML, or by attending the next Cinder meeting (1400 UTC in #openstack-meeting-alt on Wednesday 11 November). [0] https://etherpad.opendev.org/p/python-cinderclient-v2-support-removal [1] https://etherpad.opendev.org/p/cinder-wallaby-meetings From radoslaw.piliszek at gmail.com Wed Nov 4 15:54:48 2020 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Wed, 4 Nov 2020 16:54:48 +0100 Subject: [ptl] Victoria Release Community Meeting In-Reply-To: <1604353327.602612275@apps.rackspace.com> References: <1602712314.02751333@apps.rackspace.com> <1603213221.77557521@apps.rackspace.com> <20201021082822.5cocsx4zhhxs7n3q@p1.internet.domowy> <1604353327.602612275@apps.rackspace.com> Message-ID: Hi Helena, I will deliver the slides and the video for Masakari. Kind regards, -yoctozepto On Mon, Nov 2, 2020 at 11:00 PM helena at openstack.org wrote: > > Hello PTLs, > > > > The community meeting for the Victoria release will be November 12th at 16:00 UTC. Please let me know if there is a conflict with this time/date. > > > > I have attached a template for the slides that you may use if you wish. The video should be around 10 minutes. Please send in your video and slide for the community meeting EOD Friday, November 6. > > > > The community meeting will consist of the pre-recorded videos followed by a live Q&A session. > > > > Right now, we only have 4 PTLs signed up and we would welcome more folks. Please let me know if you are interested in participating. > > > > Let me know if you have any other questions! > > > > Thank you for your participation, > > Helena > > > > -----Original Message----- > From: "Slawek Kaplonski" > Sent: Wednesday, October 21, 2020 4:28am > To: "helena at openstack.org" > Cc: "Goutham Pacha Ravi" , "Kendall Nelson" , "OpenStack Discuss" > Subject: Re: [ptl] Victoria Release Community Meeting > > Hi, > > Count me in for the Neutron project. > > On Tue, Oct 20, 2020 at 01:00:21PM -0400, helena at openstack.org wrote: > > Hi Goutham and other interested PTLs, > > > > > > > > A date has not yet been set for the community meeting, but we will confirm one > > after the PTG. A week or two after PTG is when it would be a good time to have > > slides back to us; I have attached a template for the slides that you may use > > if you wish. The video should be around 10 minutes. > > > > > > > > Let me know if you have any other questions! > > > > > > > > Thank you for participating, > > > > Helena > > > > > > > > > > > > -----Original Message----- > > From: "Goutham Pacha Ravi" > > Sent: Wednesday, October 14, 2020 7:08pm > > To: "Kendall Nelson" > > Cc: "helena at openstack.org" , "OpenStack Discuss" > > > > Subject: Re: [ptl] Victoria Release Community Meeting > > > > > > Helena / Kendall, > > Interested! > > A couple of follow up questions: Should we adhere to a time limit / slide > > format? Is a date set for the community meeting? When are these recordings due? > > Thanks, > > Goutham > > > > > > On Wed, Oct 14, 2020 at 3:08 PM Kendall Nelson wrote: > > > > Hello! > > You can think of these pre-recorded snippets as Project Updates since we > > aren't doing a summit for each release anymore. We hope to get them higher > > visibility by having them recorded and posted in the project navigator. > > Hope this helps :) > > -Kendall Nelson (diablo_rojo) > > > > On Wed, Oct 14, 2020 at 2:52 PM helena at openstack.org > > wrote: > > > > > > Hi Everyone, > > > > > > > > We are looking to do a community meeting following The Open > > Infrastructure Summit and PTG to discuss the Victoria Release. If > > you’re a PTL, please let me know if you’re interested in doing a > > prerecorded explanation of your project’s key features for the release. > > We will show a compilation of these recordings at the community meeting > > and follow it with a live Q&A session. Post community meeting we will > > have this recording live in the project navigator. > > > > > > > > Cheers, > > > > Helena > > > > > > > > > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat > From anusuya at nidrive.jp Wed Nov 4 01:41:18 2020 From: anusuya at nidrive.jp (ANUSUYA MANI) Date: Wed, 4 Nov 2020 10:41:18 +0900 Subject: Openstack - File system changing to read-only mode Message-ID: Openstack - File system changing to read-only mode after 1 or 2 days of creating the instance. Not able to access any files after that. I am using Ubuntu 18.04 instances. I have installed openstack on my server which is also ubuntu 18.04. I have enough disk space. After this issues, when i try to remount , i am not able to do. what is the cause of this kind of issue and how to resolve this. Kindly help me in resolving this. Attaching logs here. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dmesg-log.JPG Type: image/jpeg Size: 200399 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: log1.JPG Type: image/jpeg Size: 317010 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: log2.JPG Type: image/jpeg Size: 278315 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: syslog-error&failed.JPG Type: image/jpeg Size: 462523 bytes Desc: not available URL: From anusuya at nidrive.jp Wed Nov 4 01:43:36 2020 From: anusuya at nidrive.jp (ANUSUYA MANI) Date: Wed, 4 Nov 2020 10:43:36 +0900 Subject: In Openstack (devstack) i am able to create maximum of 3 volumes only Message-ID: I have 3 volumes of 80GB each and when i try to create a volume snapshot or a new volume i am not able to do that. i get the error 'schedule allocate volume:Could not find any available weighted backend'. The volume quotas are set properly yet i am not able to create more than 3 volumes. i have attached screenshots of the volume quotas and error message. Kindly requesting to help me solve this issue. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: volumequota.JPG Type: image/jpeg Size: 94630 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: volumeerror.JPG Type: image/jpeg Size: 80627 bytes Desc: not available URL: From marios at redhat.com Wed Nov 4 16:47:34 2020 From: marios at redhat.com (Marios Andreou) Date: Wed, 4 Nov 2020 18:47:34 +0200 Subject: [tripleo] next meeting Tuesday Nov 10 @ 1400 UTC in #tripleo Message-ID: Hello tripleo as discussed at PTG - we voted [1] to have IRC meetings every 2 weeks and next week will be 2 weeks since PTG :) Keeping the same day and time our next meeting will be ** Tuesday 10th November at 1400 UTC in #tripleo. ** Our regular agenda is at https://wiki.openstack.org/wiki/Meetings/TripleO Please add items you want to raise at https://etherpad.opendev.org/p/tripleo-meeting-items . There were concerns voiced at PTG about low attendance in these meetings but at the same time quite a few folks voted to have it. So, let's try again and as with all the things we will re-evaluate based on all our feedback, Can I get a o/ if you plan on attending these meetings? Or even if you can't but plan to read the meetbot logs ;) Obviously now would be a good time to speak up if you hate tuesdays at 1400 UTC and want to propose some alternative for us to consider, thanks, marios [1] https://etherpad.opendev.org/p/tripleo-ptg-wallaby-community-process -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethp at gurukuli.co.uk Wed Nov 4 16:54:21 2020 From: sethp at gurukuli.co.uk (Seth Tunstall) Date: Wed, 4 Nov 2020 16:54:21 +0000 Subject: [placement] Train upgrade warning In-Reply-To: <92da9dd6-d84f-efa5-ab8e-fc8124548b89@gmail.com> References: <54217759-eed4-5330-8b55-735ab622074c@gmail.com> <1603620657403.92138@univ-lyon1.fr> <272037d7-48f7-2f10-d7fb-cd1cc7b71e87@gmail.com> <79e6ffd0-83d1-f1ab-b0fa-6a4e8fc9a93c@gmail.com> <2d6ee04a-cff7-c3ad-4a1f-221c03dc0ef3@gurukuli.co.uk> <92da9dd6-d84f-efa5-ab8e-fc8124548b89@gmail.com> Message-ID: <26c491ef-2473-00d1-8b4a-7386758ea7ec@gurukuli.co.uk> Hello, In case it helps anyone else searching for this in future: Melanie's suggestion to clean out the orphaned consumers worked perfectly in my situation. The last two I had were apparently left over from the original build of this environment. I brute-force cleaned them out of the DB manually: DELETE FROM nova_cell0.block_device_mapping WHERE nova_cell0.block_device_mapping.instance_uuid IN (SELECT uuid FROM nova_api.consumers WHERE nova_api.consumers.uuid NOT IN (SELECT nova_api.allocations.consumer_id FROM nova_api.allocations)); DELETE FROM nova_cell0.instance_faults WHERE nova_cell0.instance_faults.instance_uuid IN (SELECT uuid FROM nova_api.consumers WHERE nova_api.consumers.uuid NOT IN (SELECT nova_api.allocations.consumer_id FROM nova_api.allocations)); DELETE FROM nova_cell0.instance_extra WHERE nova_cell0.instance_extra.instance_uuid IN (SELECT uuid FROM nova_api.consumers WHERE nova_api.consumers.uuid NOT IN (SELECT nova_api.allocations.consumer_id FROM nova_api.allocations)); DELETE FROM nova_cell0.instance_info_caches WHERE nova_cell0.instance_info_caches.instance_uuid IN (SELECT uuid FROM nova_api.consumers WHERE nova_api.consumers.uuid NOT IN (SELECT nova_api.allocations.consumer_id FROM nova_api.allocations)); DELETE FROM nova_cell0.instance_system_metadata WHERE nova_cell0.instance_system_metadata.instance_uuid IN (SELECT uuid FROM nova_api.consumers WHERE nova_api.consumers.uuid NOT IN (SELECT nova_api.allocations.consumer_id FROM nova_api.allocations)); DELETE FROM nova_cell0.instances WHERE nova_cell0.instances.uuid IN (SELECT uuid FROM nova_api.consumers WHERE nova_api.consumers.uuid NOT IN (SELECT nova_api.allocations.consumer_id FROM nova_api.allocations)); Caveat: I am not intimately familiar with how the ORM handles these DB tables, I may have done something stupid here. I tried to run: nova-manage db archive_deleted_rows --verbose --until-complete --all-cells but nova-db-manage complained that it didn't recognise --no-cells Thanks very much for your help, Melanie Seth On 30/10/2020 16:50, melanie witt wrote: > On 10/30/20 01:37, Seth Tunstall wrote: >> Hello, >> >> On 10/28/20 12:01, melanie witt wrote: >>  >> The main idea of the row deletions is to delete "orphan" records >> which are records tied to an instance's lifecycle when that instance >> no longer exists. Going forward, nova will delete these records itself >> at instance deletion time but did not in the past because of bugs, and >> any records generated before a bug was fixed will become orphaned once >> the associated instance is deleted. >> >> I've done the following in this order: >> >> nova-manage api_db sync >> >> nova-manage db sync >> >> (to bring the DBs up to the version I'm upgrading to (Train) >> >> nova-manage db archive_deleted_rows --verbose --until-complete > > The thing I notice here ^ is that you didn't (but should) use > --all-cells to also clean up based on the nova_cell0 database (where > instances that failed scheduling go). If you've ever had an instance go > into ERROR state for failing the scheduling step and you deleted it, its > nova_api.instance_mappings record would be a candidate for being > archived (removed). > > > >> # placement-status upgrade check >> +-----------------------------------------------------------------------+ >> | Upgrade Check Results | >> +-----------------------------------------------------------------------+ >> | Check: Missing Root Provider IDs | >> | Result: Success | >> | Details: None | >> +-----------------------------------------------------------------------+ >> | Check: Incomplete Consumers | >> | Result: Warning | >> | Details: There are -2 incomplete consumers table records for existing | >> | allocations. Run the "placement-manage db | >> | online_data_migrations" command. | >> +-----------------------------------------------------------------------+ >> >> argh! again a negative number! But at least it's only 2, which is well >> within the realm of manual fixes. > > The only theory I have for how this occurred is you have 2 consumers > that are orphaned due to missing the nova_cell0 during database > archiving ... Like if you have a couple of deleted instances in > nova_cell0 and thus still have nova_api.instance_mappings and without > --all-cells those instance_mappings didn't get removed and so affected > the manual cleanup query you ran (presence of instance_mappings > prevented deletion of 2 orphaned consumers). > > If that's not it, then I'm afraid I don't have any other ideas at the > moment. > > -melanie From sethp at gurukuli.co.uk Wed Nov 4 16:54:32 2020 From: sethp at gurukuli.co.uk (Seth Tunstall) Date: Wed, 4 Nov 2020 16:54:32 +0000 Subject: [placement] Train upgrade warning In-Reply-To: <92da9dd6-d84f-efa5-ab8e-fc8124548b89@gmail.com> References: <54217759-eed4-5330-8b55-735ab622074c@gmail.com> <1603620657403.92138@univ-lyon1.fr> <272037d7-48f7-2f10-d7fb-cd1cc7b71e87@gmail.com> <79e6ffd0-83d1-f1ab-b0fa-6a4e8fc9a93c@gmail.com> <2d6ee04a-cff7-c3ad-4a1f-221c03dc0ef3@gurukuli.co.uk> <92da9dd6-d84f-efa5-ab8e-fc8124548b89@gmail.com> Message-ID: Hello, In case it helps anyone else searching for this in future: Melanie's suggestion to clean out the orphaned consumers worked perfectly in my situation. The last two I had were apparently left over from the original build of this environment. I brute-force cleaned them out of the DB manually: DELETE FROM nova_cell0.block_device_mapping WHERE nova_cell0.block_device_mapping.instance_uuid IN (SELECT uuid FROM nova_api.consumers WHERE nova_api.consumers.uuid NOT IN (SELECT nova_api.allocations.consumer_id FROM nova_api.allocations)); DELETE FROM nova_cell0.instance_faults WHERE nova_cell0.instance_faults.instance_uuid IN (SELECT uuid FROM nova_api.consumers WHERE nova_api.consumers.uuid NOT IN (SELECT nova_api.allocations.consumer_id FROM nova_api.allocations)); DELETE FROM nova_cell0.instance_extra WHERE nova_cell0.instance_extra.instance_uuid IN (SELECT uuid FROM nova_api.consumers WHERE nova_api.consumers.uuid NOT IN (SELECT nova_api.allocations.consumer_id FROM nova_api.allocations)); DELETE FROM nova_cell0.instance_info_caches WHERE nova_cell0.instance_info_caches.instance_uuid IN (SELECT uuid FROM nova_api.consumers WHERE nova_api.consumers.uuid NOT IN (SELECT nova_api.allocations.consumer_id FROM nova_api.allocations)); DELETE FROM nova_cell0.instance_system_metadata WHERE nova_cell0.instance_system_metadata.instance_uuid IN (SELECT uuid FROM nova_api.consumers WHERE nova_api.consumers.uuid NOT IN (SELECT nova_api.allocations.consumer_id FROM nova_api.allocations)); DELETE FROM nova_cell0.instances WHERE nova_cell0.instances.uuid IN (SELECT uuid FROM nova_api.consumers WHERE nova_api.consumers.uuid NOT IN (SELECT nova_api.allocations.consumer_id FROM nova_api.allocations)); Caveat: I am not intimately familiar with how the ORM handles these DB tables, I may have done something stupid here. I tried to run: nova-manage db archive_deleted_rows --verbose --until-complete --all-cells but nova-db-manage complained that it didn't recognise --no-cells Thanks very much for your help, Melanie Seth On 30/10/2020 16:50, melanie witt wrote: > On 10/30/20 01:37, Seth Tunstall wrote: >> Hello, >> >> On 10/28/20 12:01, melanie witt wrote: >>  >> The main idea of the row deletions is to delete "orphan" records >> which are records tied to an instance's lifecycle when that instance >> no longer exists. Going forward, nova will delete these records itself >> at instance deletion time but did not in the past because of bugs, and >> any records generated before a bug was fixed will become orphaned once >> the associated instance is deleted. >> >> I've done the following in this order: >> >> nova-manage api_db sync >> >> nova-manage db sync >> >> (to bring the DBs up to the version I'm upgrading to (Train) >> >> nova-manage db archive_deleted_rows --verbose --until-complete > > The thing I notice here ^ is that you didn't (but should) use > --all-cells to also clean up based on the nova_cell0 database (where > instances that failed scheduling go). If you've ever had an instance go > into ERROR state for failing the scheduling step and you deleted it, its > nova_api.instance_mappings record would be a candidate for being > archived (removed). > > > >> # placement-status upgrade check >> +-----------------------------------------------------------------------+ >> | Upgrade Check Results | >> +-----------------------------------------------------------------------+ >> | Check: Missing Root Provider IDs | >> | Result: Success | >> | Details: None | >> +-----------------------------------------------------------------------+ >> | Check: Incomplete Consumers | >> | Result: Warning | >> | Details: There are -2 incomplete consumers table records for existing | >> | allocations. Run the "placement-manage db | >> | online_data_migrations" command. | >> +-----------------------------------------------------------------------+ >> >> argh! again a negative number! But at least it's only 2, which is well >> within the realm of manual fixes. > > The only theory I have for how this occurred is you have 2 consumers > that are orphaned due to missing the nova_cell0 during database > archiving ... Like if you have a couple of deleted instances in > nova_cell0 and thus still have nova_api.instance_mappings and without > --all-cells those instance_mappings didn't get removed and so affected > the manual cleanup query you ran (presence of instance_mappings > prevented deletion of 2 orphaned consumers). > > If that's not it, then I'm afraid I don't have any other ideas at the > moment. > > -melanie From mark at stackhpc.com Wed Nov 4 17:06:30 2020 From: mark at stackhpc.com (Mark Goddard) Date: Wed, 4 Nov 2020 17:06:30 +0000 Subject: [kolla] Kolla klub meetings paused Message-ID: Hi, We agreed at the PTG to try rebooting the Kolla klub meetings at a different time to involve some new members. Let's pause the meetings until then. Regards, Mark From melwittt at gmail.com Wed Nov 4 17:08:50 2020 From: melwittt at gmail.com (melanie witt) Date: Wed, 4 Nov 2020 09:08:50 -0800 Subject: [placement] Train upgrade warning In-Reply-To: References: <54217759-eed4-5330-8b55-735ab622074c@gmail.com> <1603620657403.92138@univ-lyon1.fr> <272037d7-48f7-2f10-d7fb-cd1cc7b71e87@gmail.com> <79e6ffd0-83d1-f1ab-b0fa-6a4e8fc9a93c@gmail.com> <2d6ee04a-cff7-c3ad-4a1f-221c03dc0ef3@gurukuli.co.uk> <92da9dd6-d84f-efa5-ab8e-fc8124548b89@gmail.com> Message-ID: <90557ebe-caec-bfa7-79f1-f909474235ff@gmail.com> On 11/4/20 08:54, Seth Tunstall wrote: > Hello, > > In case it helps anyone else searching for this in future: Melanie's > suggestion to clean out the orphaned consumers worked perfectly in my > situation. > > The last two I had were apparently left over from the original build of > this environment. I brute-force cleaned them out of the DB manually: > > DELETE FROM nova_cell0.block_device_mapping WHERE > nova_cell0.block_device_mapping.instance_uuid IN (SELECT uuid FROM > nova_api.consumers WHERE nova_api.consumers.uuid NOT IN (SELECT > nova_api.allocations.consumer_id FROM nova_api.allocations)); > Caveat: I am not intimately familiar with how the ORM handles these DB > tables, I may have done something stupid here. Hm, sorry, this isn't what I was suggesting you do ... I was making a guess that you might have instances with 'deleted' != 0 in your nova_cell0 database and that if so, they needed to be archived using 'nova-manage db archive_deleted_rows' and then that might take care of removing their corresponding nova_api.instance_mappings which would make the manual cleanup find more rows (the rows that were being complained about). What you did is "OK" (not harmful) if the nova_cell0.instances records associated with those records were 'deleted' column != 0. But there's likely more cruft rows left behind that will never be removed. nova-manage db archive_deleted_rows should be used whenever possible because it knows how to remove all the things. > I tried to run: > > nova-manage db archive_deleted_rows --verbose --until-complete --all-cells > > but nova-db-manage complained that it didn't recognise --no-cells This is with the train code? --all-cells was added in train [1]. If you are running with code prior to train, you have to pass a nova config file to the nova-manage command that has its [api_database]connection set to the nova_api database connection url and the [database]connection set to the nova_cell0 database. Example: nova-manage --config-file db archive_deleted_rows ... Cheers, -melanie [1] https://docs.openstack.org/nova/train/cli/nova-manage.html#nova-database From piotrmisiak1984 at gmail.com Wed Nov 4 17:45:01 2020 From: piotrmisiak1984 at gmail.com (Piotr Misiak) Date: Wed, 4 Nov 2020 18:45:01 +0100 Subject: [neutron][ovn] Neutron <-> OVN DB synchronization code Message-ID: Hi, Do you know why Neutron <-> OVN DB sync code synchronizes "DEVICE_OWNER_ROUTER_HA_INTF" router ports here in this line: https://github.com/openstack/neutron/blob/164f12349fd8be09b9fd4f23b8cf8d2f3eccd11b/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_db_sync.py#L460 ? As far as know there is no need for HA network ports for L3 virtual routers implementation in OVN, because OVN uses the internal BFD mechanism for Gateway Chassis reachability tests. Thanks, Piotr -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 2464 bytes Desc: not available URL: From vladimir.blando at gmail.com Wed Nov 4 18:37:20 2020 From: vladimir.blando at gmail.com (vladimir franciz blando) Date: Wed, 4 Nov 2020 12:37:20 -0600 Subject: Editing libvirt xml file In-Reply-To: References: Message-ID: Already found a solution which entails hacking nova database, specifically the instance_system_metadata table Regards Vlad On Fri, Oct 30, 2020 at 4:57 PM vladimir franciz blando < vladimir.blando at gmail.com> wrote: > Yes, I am fully aware of support implications if you edit this. But > fortunately this is not in any way a vendor support OpenStack deployment > > On Fri, Oct 30, 2020 at 1:29 PM Sean Mooney wrote: > >> On Fri, 2020-10-30 at 17:23 +0000, Stephen Finucane wrote: >> > On Fri, 2020-10-30 at 11:56 -0500, vladimir franciz blando wrote: >> > > Hi, >> > > I edited the libvirt xml (virsh edit...) file of a running Windows >> > > server instance because I changed the video model type from cirrus to >> > > vmvga so it can support a higher resolution on a console (cirrus >> > > supports up to 1280 only). >> > > After editing, i "soft-rebooted" the instance and the new >> > > configuration sticks. That's awesome. >> > >> > Please don't do this :) You shouldn't change things about an instance >> > behind nova's back. It breaks resource tracking and can cause all sorts >> > of horribleness. >> >> if you have support form an openstack vendor like redhat editing the >> domain >> xml also make that vm unsupported until its restroed to the way nova >> generated. >> it might also make other issue caused as a resulted unsupported. >> so unless you are self supporting you cloud be very carful with doing >> this. >> > >> > > But when you do a "hard-reboot" it will revert back to the original >> > > config. >> > >> > Hard reboot builds configuration from scratch, dumping the existing >> > XML. This is built from the same things used when you first create the >> > instance (flavor + extra specs, image + metadata, host-level config, >> > ...). >> > >> > What you want is the 'hw_video_model' image metadata property. Set this >> > and rebuild your instance: >> > >> > openstack image set --property hw_video_model=vmvga $IMAGE >> this is the supported way to change this value ^ >> it will take effect for new instances. >> > openstack server rebuild $SERVER $IMAGE >> and this is the only supported api action that can also change this value. >> however i dont think rebuilding to the same image will update the image >> metadata. >> you currenlty need to rebuild to a new image. this is due to an >> optiomisation we >> have to avoid needing to go to the scheuler if we use the same image. >> >> the unsupported way to change this without rebuilding the instance is to >> add >> img_hw_video_model=vmvga to the system metadata table for that instance. >> >> if your cloud is supported by a vendor this will also invalidate your >> suport >> in all likely hood as db modificaiton generally are unsupported without >> an exception. >> if you can rebuild the guest that is the best approch but it wont work >> for boot form volume >> instances and it willl destory all data in the root disk of all other >> instances. >> >> > >> > Note that rebuild is a destructive operation so be sure you're aware of >> > what this is doing before you do it. >> > >> > Stephen >> > >> > > I also tried to do a "shut-down" then "start" again, but it still >> > > reads the original config. Not sure where it is reading the config >> > > from... >> > > >> > > Regards >> > > Vlad >> > >> > >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Wed Nov 4 20:12:30 2020 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Wed, 4 Nov 2020 21:12:30 +0100 Subject: [masakari] Teams cleanup Message-ID: Hello Everyone! To avoid the ghost town effect in Masakari teams, I propose to clean up the memberships. I've already had a chance to discuss it with Takashi Kajinami on IRC [0] as he wanted to remove himself. We have 3 teams (1 gerrit, 2 launchpad): - Gerrit masakari-core [1] - Launchpad masakari-drivers [2] - Launchpad masakari-bugs [3] I plan to set these to the following people: - myself [Radosław Piliszek] (the new PTL) - suzhengwei (new active contributor and core) - Jegor van Opdorp (new active contributor and core) - Sampath Priyankara (the previous PTL) - Tushar Patil (the previously most active core) I will enact the change in a week from now if there are no objections. I also see a few issues likely to discuss with the infra team: 1) Launchpad masakari-drivers - there is a pending invitation for the release team - I doubt it has much use but I would love to see it accepted/rejected/accepted&removed. 2) Gerrit masakari-core - there is an external CI in the core team - why would it need this level of privilege? It does not add its flags to changes, only replies with job status. [0] http://eavesdrop.openstack.org/irclogs/%23openstack-masakari/%23openstack-masakari.2020-10-21.log.html#t2020-10-21T12:42:14 [1] masakari-core: https://review.opendev.org/#/admin/groups/1448,members [2] https://launchpad.net/~masakari-drivers/+members [3] https://launchpad.net/~masakari-bugs/+members Kind regards, -yoctozepto From melwittt at gmail.com Wed Nov 4 23:30:20 2020 From: melwittt at gmail.com (melanie witt) Date: Wed, 4 Nov 2020 15:30:20 -0800 Subject: [gate][all] assorted tempest jobs fail when IPv4 default route is not available Message-ID: <772eb358-2eb0-3bfb-cfd5-a9c8df333b1e@gmail.com> Hi all, We have a gate bug [1] where if a CI VM does not have an IPv4 default route configured, the job will fail with one of the following errors: "[ERROR] /opt/stack/devstack/functions-common:230 Failure retrieving default route device" [2] or "[ERROR] /opt/stack/devstack/functions-common:104 Failure retrieving default IPv4 route devices" [3] because the die_if_not_set is being triggered. Most of the time, CI VMs come configured with an IPv4 default route but something changed recently (around Oct 23 or 24) to where we often get VMs that do not have an IPv4 default route configured and presumably only have an IPv6 default route. According to this logstash query [4] we have: 58 hits in the last 7 days, check and gate, all failures, all on the limestone-regionone node provider, various projects, various jobs Nate Johnson has proposed a fix here: https://review.opendev.org/761178 Reviews appreciated. Cheers, -melanie [1] https://bugs.launchpad.net/devstack/+bug/1902002 [2] example: https://zuul.openstack.org/build/7543021732cc4886b608553da58e81f9/log/controller/logs/devstacklog.txt#134 [3] example: https://zuul.opendev.org/t/openstack/build/7fff839dd0bc4214ba6470ef40cf78fd/log/job-output.txt#1875 [4] http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22failure%20retrieving%20default%5C%22%20AND%20tags:%5C%22devstacklog.txt%5C%22%20AND%20message:%5C%22ERROR%5C%22&from=7d From gouthampravi at gmail.com Wed Nov 4 23:54:57 2020 From: gouthampravi at gmail.com (Goutham Pacha Ravi) Date: Wed, 4 Nov 2020 15:54:57 -0800 Subject: [manila][ptg] Manila Wallaby PTG Summary Message-ID: Hello Zorillas and all other interested Stackers! The OpenStack Manila Project Technical Gathering for the Wallaby development cycle was a successful meeting of project developers, users, operators and contributors to the rest of OpenStack, Kubernetes, Ceph and other communities - simply all zorillas and friends! I would like to thank the PTG organizing committee, (the Kendalls! :D) the infrastructure team, and everyone that contributed to the discussions. The following is my summary of the proceedings. I've linked associated etherpads, and resources to dig in further, and chat with us here, or on freenode's #openstack-manila! == Day 1 - Oct 26, 2020, Mon == === Manila Interop testing === Topic Etherpad: https://etherpad.opendev.org/p/wallaby-ptg-manila-interop Discussion Items: - OSF Foundation Board and Interop Working Group members were apprised about Manila, its capabilities and problem space - Manila contributors answered questions regarding user workflows, tempest integration, vendor coverage and project maturity - Manila's addition to the Interop refstack suite will allow: * OpenStack clouds and distributions to certify their manila APIs for the "OpenStack Powered" trademark program, as well as, * OpenStack Manila third party integrations can claim the "OpenStack Compatible" label - A plan was charted to target an upcoming interop advisory with manila as an "Add-On" component - Interop team presented their idea for E2E testing for running container workloads on top of openstack Actions: - Vida Haririan (vhari), Liron Kuchlani (lkuchlan) and Goutham Pacha Ravi (gouthamr) will create the interop test plan for Manila - Test plan target is the upcoming 2020.10 advisory === Manila Retrospective === Topic Etherpad: https://etherpad.opendev.org/p/manila-victoria-retrospective Discussion Items: - Victoria Cycle Bug/Documentation Squash days were a big hit. 45% of the bug backlog was addressed with these squashes - thanks vhari/vkmc! - Team's doing a great job of farming low-hanging-fruit; but resolution is taking longer, we should timebox fixes for Medium prio low-hanging-fruit; high prio bugs cannot be tagged "low-hanging-fruit" - Team recognized the mentorship eagerness, and the opportunity providers in Victoria/Wallaby - Grace Hopper Celebration, Outreachy, Boston University Project and other venues - We couldn't complete the "migrate to focal fossa goal" - team was short handed at the end of the release, thanks to the goal champion, Ghanshyam Mann for ensuring we can make decent progress and target completion in wallaby - New TC tags (kubernetes-in-virt, assert:supports-accessible-upgrade, erstwhile tc:approved-release) were great, more to come in Wallaby (vulnerability-managed, supports-api-interoperability) - A GREAT DEAL of work was done on manila-tempest-plugin, and the team is thankful, and is sure users are appreciative of the focus we have on CI. - Great PTL leadership - but there's room to grow :D - Collaborative review sessions are a hit. Let's keep doing them! Actions: - We'll have a bug squash event closer to Wallaby-1 for bigger bugs that require API/DB changes as identified in the last Cycle (vkmc/vhari) - We'll have Bug/Documentation Squash after Wallaby-3 as well - Work on TC tags by Wallaby-1 - Contributors can actively seek Collaborative Review sessions for the work they're doing - CI flakiness needs to be audited and recurring test failures will be identified (dviroel) and discussed at an upcoming IRC meeting - Backend Feature Support Matrix will be improved and doc bugs will be filed for other issues identified (dviroel) === Cephadm, Triple-O and NFS-Ganesha === Topic Etherpad: https://etherpad.opendev.org/p/tripleo-ceph Discussion Items: - fultonj/gfidente/fpantano presented three specs to chart the future of ceph deployment with tripleo. The ceph community will no longer support ceph-ansible as a deployment tool. - particularly interesting to the manila team was the fate of nfs-ganesha ("ceph-nfs") which doesn't have adequate support in ceph's new deployment tooling (cephadm and ceph orch) to cover tripleo's requirements of HA, or allow deployment flexibility like ceph-ansible used to (ceph-ansible would allow deploying nfs-ganesha as a standalone service on tripleo hosts) - the proposal was to retain the portions of ceph-ansible that were used for nfs-ganesha in tripleo while replacing the use of ceph-ansible with cephadm/ceph orch. - tripleo contributors were concerned about the future supportability of taking over the portion of the setup that ceph ansible does for tripleo today; they would be more comfortable if cephadm can be fixed in time for wallaby, or the portions of the code taken from ceph-ansible be in an independent repo Actions: - pursue cephadm/orch support for nfs-ganesha with ceph-orchestration team and understand timeline and upgrade implications when substituting the work - advance the work via specs == Day 2 - Oct 27, 2020, Tue == === Sub teams === Topic Etherpad: https://etherpad.opendev.org/p/wallaby-ptg-manila-subteams Discussion Items: - gouthamr/vkmc proposed that client repos (python-manilaclient, manila-ui) and tempest (manila-tempest-plugin) have their own core teams - manila-core can be part of the initial core teams of those repos - the idea is to create focussed subteams that can to some degree of autonomy, govern these projects with the domain knowledge they have, have independent meetings and bug triages if they wish and dictate a roadmap - this way, review bandwidth can be adequately shared - the sub teams will allow manila core team mentoring efforts and provide an easier on ramp for new maintainers - team agreed that this is a good way forward, and acknowledged that they would not want to create more maintenance burden or create silos. Actions: - get https://review.opendev.org/758868/ merged - to avoid siloing, weekly IRC meeting will call upon subteams to share updates - focussing on a sub project doesn't mean we don't pay attention to other repos - attempt to record mentoring sessions and post it publicly for posterity === Extending shares via the Manila scheduler === Topic Etherpad: https://etherpad.opendev.org/p/share-stuck-in-extend-discussion Discussion Items: - manila share extension currently doesn't go through the scheduler - they directly hit the share service/host responsible for the share ( https://bugs.launchpad.net/manila/+bug/1855391) - this needs to be fixed for two reasons - a) capacity based calculations are off if scheduler is ignored, b) service health checks are not accounted for - there was a concern this change would break administrators that rely on this wrong behavior as storage pools fill up - this was called out as a corner case, and instead of having a global way to opt-in/out of using the scheduler for share extensions, we can build a "force" flag for privileged users that will preserve existing behavior Actions: - haixin will propose changes to the patch based on this feedback === Virtio-FS === Topic Etherpad: https://etherpad.opendev.org/p/nova-manila-virtio-fs-support-vptg-october-2020 Discussion Items: - virtiofs support has debuted in newer linux kernels and the libvirt/qemu/kvm communities have adopted it - in OpenStack, Nova can be made to use virtio-fs and expose Manila shares to tenant VMs - this provides a user experience improvement for manila users where mount automation has been a concern for a while, along with the desire to have strong multi-tenant separation on the network path which only a subset of manila backends are able to provide directly - virtiofs support does not replace DHSS=True or use of gateways like NFS-Ganesha (e.g.: CephFS, GPFS, etc) since those are still very much valuable when the consumer isn't nova VMs but baremetals, containers or non-OpenStack VMs. - nova team helped understand the feature submission process and provided guidance on how to integrate this feature in stages - the user experience, data models and cross service RPCs for this can be modeled around block device mapping, however we don't need to share or copy the implementation - this is surely a large multi-cycle work - nova team suggested that we begin with only attach/detach workflows in Wallaby Actions: - tbarron will propose a nova spec to allow "nova attach fs" (and detach) workflows - we'll continue to design "boot with share" or "boot from share" APIs, including scheduler changes through this cycle === Share Server Updates === Topic Etherpad: https://etherpad.opendev.org/p/share-server-update Discussion Items: - objective is to be able to update security services and share network subnets after share servers have been provisioned - users that want to make these updates have no access to share servers - a security service update can impact multiple share networks (and hence multiple share servers) and in turn multiple share resources, so there was a concern with granularity of the update - operators don't want to be involved with the updates, want users to be able to make the updates on resources they can see (security services or share networks) - if we allow end users to make these changes, we'll still need to break down the operation into more granular bits, and provide APIs to perform validation and multi-step updates Actions: - dviroel will propose spec updates based on the feedback gathered here: https://review.opendev.org/729292 - need other DHSS=True driver maintainers to pay attention to these changes === Share Affinity Hints === Topic Etherpad: https://etherpad.opendev.org/p/manila-anti-affinity Discussion Items: - need a way to specify affinity or anti-affinity placement hints wrt existing resources (e.g: shares, share groups) - share groups provide a way to indicate affinity, but they may also encase shares into a construct and make individual operations on shares harder (you cannot add existing shares to a group or remove shares from a share group without deleting them, you can only create new members in a share group) - need a vehicle other than groups or share type extra specs to carry scheduling decisions that affect single shares - this mechanism shouldn't break cloud storage abstraction - cinder has had the ability for end users to add placement hints for affinity without breaking abstractions Actions: - carthaca will propose a specification for this work - we'll seek reviews from cinder contributors on the spec == Day 3 - Oct 28, 2020, Wed == === Responsibility for Code Reviews === Topic Etherpad: https://etherpad.opendev.org/p/wallaby-ptg-manila Discussion Items: - a bulk of the day-2 operations that are being enhanced have significant impact on vendor driver implementations - we do have first party "reference" driver support for testing and designing manila APIs in a generic fashion but, not having vendor driver maintainer feedback is unfortunate - operator feedback is also very much appreciated, and we've made significant decisions because of it Actions: - proposers for new features that affect drivers must actively seek out vendor driver maintainers and operators and add them to review. The team will help identify these individuals - we'll track vendor/operator feedback and reviews as part of the review focus tracking we do through the cycle === Acting on Deprecation removals === Topic Etherpad: https://etherpad.opendev.org/p/wallaby-ptg-manila Discussion Items: - tbarron proposed https://review.opendev.org/745206/ to remove old deprecated config options from manila - we should be doing this more actively each cycle, however, we held off from merging the code change above considering the impact to configuration and deployment tooling - driver module maintainers must adjust the deployment tooling/other usages accordingly asap Actions: - dviroel, carloss and gouthamr will review and merge https://review.opendev.org/745206/ === rootwrap-to-privsep migration === Topic Etherpad: https://etherpad.opendev.org/p/manila-migration-from-rootwrap-to-privsep Discussion Items: - this has been selected as a community goal for Wallaby - privsep has not been used in manila so far - most first party and reference drivers (lvm, zfsonlinux, generic, container, ceph) use rootwrap heavily - some third party drivers also use rootwrap - team was concerned with the completion criteria wrt third party drivers - a stretch goal would be to investigate if dropping privileges for operations by substituting mechanisms is possible Actions: - carloss will work on this goal, no specification is necessary - adequate testing, admin/operator documentation will be provided - carloss will reach out to the third party driver maintainers to act on rootwrap removals - carloss/team will attack de-escalation/removing use of root privs to perform an operation, opportunistically === Secure RBAC improvements === Topic Etherpad: https://etherpad.opendev.org/p/wallaby-ptg-manila-policy-changes Discussion Items: - manila will need to support splitting of the existing admin, member roles to system, domain and project admins and members - operators can define personas with these default roles using keystone's "role scope" - an accompanying feature is to provide "reader" role permissions as well - manila accepts the use of "policy.yaml" to drive RBAC, over "policy.json", but, the default is still "policy.json" and this needs to change due to several challenges, including the ability to have comments in the files Actions: - gouthamr will propose a spec for policy refresh across manila APIs/resources using these new role personas - making policy.yaml the default for policy overrides is going to be a community goal. We're targeting this transition to wallaby-1 in manila - we'll attempt to complete this effort in wallaby. there are several parts, collaboration is welcome! === CephFS Updates === Topic Etherpad: https://etherpad.opendev.org/p/wallaby-ptg-manila-cephfs-driver-update Discussion Items: - vkmc provided an update on the cephfs feature roadmap - we need changes in cephfs (preferably in ceph-nautilus) to perform authorization, subvolume cloning, capacity reporting etc. This work is being tracked through tracker tickets in Ceph's tracking system - we stopped using shaman builds for ceph and nfs-ganesha in victoria cycle - consuming nfs-ganesha from ppa's has introduced new scenario test failures, vkmc is currently triaging them Actions: - start testing ceph octopus in the wallaby cycle - keep momentum on the ceph trackers and switch over from ceph-volume-client to ceph-mgr and implement create share from snapshot in the cephfs drivers - engage with ceph and nfs-ganesha communities to create a support matrix across nfs-ganesha versions, manila and cephfs === Divisive Language Correction === Topic Etherpad: https://etherpad.opendev.org/p/wallaby-ptg-manila Discussion Items: - spotz joined us, and recapped the diversity and inclusion wg's work so far - manila team is determined to help resolve any divisive language and references in code and documentation - the team realizes that unconscious use of negative language is affecting the community's inherent desire to be welcoming and inclusive - no manila architecture or code references currently *need* the use of the divisive words identified by the working group and the wider openstack community - making changes is important to us, but we recognize it's just part of the story Actions: - we'll begin with a documentation change to remove the words identified in https://etherpad.opendev.org/p/divisivelanguage - we'll wait to coordinate a change of name for the development/trunk branch, and other "upstream" changes to databases, git, opendev - team actively welcomes any feedback == Day 5 - Oct 30, 2020, Fri == === Share and Server Migration graduation === Topic Etherpad: https://etherpad.opendev.org/p/wallaby-ptg-manila Discussion Items: - we've graduated one major feature through the last couple of cycles, share migration is next - team agreed to keep share server migration as experimental APIs since they haven't had sufficient soak time - no significant changes have been made to share migration migration APIs since Ocata, leading to believe the APIs are stable and can be improved via microversions where necessary - not a lot of vendor driver implementations for driver optimized migration, NetApp driver only allows moving within a backend at the moment - generic migration improvements have been deprioritized, and need help in terms of High Availability of the Data service as well as providing a jobs table to track, and coordinate ongoing migrations - tests are being skipped at the gate because of flakiness Actions: - team will get in touch with third party vendors and guage interest in implementing driver optimized migration (or testing/supporting generic migration with their drivers) (carloss). Feedback from the vendors will drive our decision to graduate the share migration APIs in Wallaby. === Metadata for all share resources === Topic Etherpad: https://etherpad.opendev.org/p/wallaby-ptg-manila-metadata-controller Discussion Items: - the proposal is to introduce a metadata API controller that can be inherited by the resource controllers - all user facing resources will have metadata capabilities, with consistent API methods - this is expected to benefit automation use cases, manila-csi and the upcoming virtio-fs effort Actions: - gouthamr will propose the spec for team's review, including identifying the resources that will be targeted in the Wallaby release - share metadata APIs will be improved to adhere to the API SIG spec: https://specs.openstack.org/openstack/api-sig/guidelines/metadata.html === Client Project updates === Topic Etherpads: https://etherpad.opendev.org/p/manila-osc-wallaby-ptg and https://etherpad.opendev.org/p/manila-ui-wallaby-ptg Discussion Items: - the team met with Nicole Chen, Ashley Rodriguez, Mark Tony from Boston University who will be working on the OpenStackSDK integration for Manila APIs - maaritamm provided an update on the OSC plugin interface implementation - vkmc provided an update on manila-ui feature gaps and the upcoming Outreachy internship Actions: - for some OSC plugin command implementations, we'll benefit from integrating with OpenStackSDK rather than manilaclient SDK, so we'll coordinate that work - maaritamm/vkmc will send an email to openstack-discuss to prioritize the commands left to implement in the OSC plugin - vkmc will drive consistency across cinder/manila for the user messages dashboards that were added in Victoria - we'll continue to work on closing the feature gap in manila-ui === Manila CSI Wallaby roadmap === Topic Document: https://docs.google.com/document/u/1/d/1YJcv0EROWzYbV_8DM3DHVvDqdhlPhYRV8Npl7latttY/edit# Discussion Items: - users of manila-csi today deploy one driver per share protocol - future work on monitoring, common node plugin interactions requires us to rework the architecture to have one driver multiplex with multiple share protocol node plugins - upgrade impact as well as UI/UX impact was discussed and gman0 has documented them - share metadata is necessary to tag and identify shares Actions: - gman0 has started working on the code patches, and will benefit from reviews - mfedosin will take a look at the upgrade impact and share details for automation that can be done in the csi-operator - mfedosin will test gman0's latest patch to add share metadata via the storage class (as will folks from CERN) and provide feedback Thanks for reading thus far, there were a number of items that we couldn't cover, that you can see on the PTG Planning etherpad [1], if you own those topics, please add them to the weekly IRC meeting agenda [2] and we can go over them. The master meeting minutes document is available as well [3]. As usual, the whole PTG was recorded and posted on the OpenStack Manila Youtube channel [4] We had a great turn out and we heard from a diverse set of contributors, operators, interns and users from several affiliations and time zones. On behalf of the OpenStack Manila team, I deeply appreciate your time, and help in keeping the momentum on the project! [1] https://etherpad.opendev.org/p/wallaby-ptg-manila-planning [2] https://wiki.openstack.org/wiki/Manila/Meetings [3] https://etherpad.opendev.org/p/wallaby-ptg-manila [4] https://www.youtube.com/playlist?list=PLnpzT0InFrqATBbJ60FesKGYRejnTIoCW -------------- next part -------------- An HTML attachment was scrubbed... URL: From laurentfdumont at gmail.com Thu Nov 5 01:38:54 2020 From: laurentfdumont at gmail.com (Laurent Dumont) Date: Wed, 4 Nov 2020 20:38:54 -0500 Subject: Openstack - File system changing to read-only mode In-Reply-To: References: Message-ID: What is the underlying storage system for the VM? Ceph? ISCSI? Local Storage? It looks like there could have been a storage/network blip and the OS FS might have been set RO. You should be able to run an fsck during the boot and see if that removes the RO flag. On Wed, Nov 4, 2020 at 12:02 PM ANUSUYA MANI wrote: > Openstack - File system changing to read-only mode after 1 or 2 days of > creating the instance. Not able to access any files after that. I am using > Ubuntu 18.04 instances. I have installed openstack on my server which is > also ubuntu 18.04. I have enough disk space. After this issues, when i try > to remount , i am not able to do. what is the cause of this kind of issue > and how to resolve this. Kindly help me in resolving this. Attaching logs > here. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From akekane at redhat.com Thu Nov 5 08:47:48 2020 From: akekane at redhat.com (Abhishek Kekane) Date: Thu, 5 Nov 2020 14:17:48 +0530 Subject: [glance] Single store support removal Message-ID: Hi All The Single store glance support(default) was deprecated in Rocky release by Change-Id: I50189862454ada978eb401ec24a46988517ea73b The glance team will start working on removing single store support from the wallaby cycle and intended it to finish the same in wallaby or during milestone 1 of the next cycle. Below is the roadmap for removing single store configuration support from glance and glance_store repository. 1. Default Glance to configure multiple stores - Wallaby milestone 1 - https://review.opendev.org/#/c/741802/ 2. Convert single store unit and functional tests to use multiple stores - Wallaby milestone 1 3. Remove use of single store from glance - Wallaby milestone 2 4. Remove single stores support from glance_store - Wallaby milestone 3 to X milestone 1 We would like to encourage our users to start moving to multiple stores of glance if you are still using traditional single stores of glance in your deployments. Please let us know if you have any queries or suggestions about the same. Thank you, Abhishek -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry at openstack.org Thu Nov 5 11:01:31 2020 From: thierry at openstack.org (Thierry Carrez) Date: Thu, 5 Nov 2020 12:01:31 +0100 Subject: [Release-job-failures] Release of openstack/ansible-role-redhat-subscription for ref refs/tags/1.1.1 failed In-Reply-To: References: Message-ID: zuul at openstack.org wrote: > - release-openstack-python https://zuul.opendev.org/t/openstack/build/652843f2641e47d781264a815a14894d : POST_FAILURE in 2m 54s During the release job for ansible-role-redhat-subscription 1.1.1, twine upload to PyPI failed with: HTTPError: 400 Bad Request from https://upload.pypi.org/legacy/ The description failed to render in the default format of reStructuredText. See https://pypi.org/help/#description-content-type for more information. It's weird because it looks like this was addressed about a year ago, and nothing significant changed in that area in the months following 1.1.0 release. Current status: Tag was pushed OK No tarball upload No PyPI upload Once the issue is fixed, the tag reference should be reenqueued. -- Thierry Carrez (ttx) From marios at redhat.com Thu Nov 5 12:05:03 2020 From: marios at redhat.com (Marios Andreou) Date: Thu, 5 Nov 2020 14:05:03 +0200 Subject: [Release-job-failures] Release of openstack/ansible-role-redhat-subscription for ref refs/tags/1.1.1 failed In-Reply-To: References: Message-ID: On Thu, Nov 5, 2020 at 1:03 PM Thierry Carrez wrote: > zuul at openstack.org wrote: > > - release-openstack-python > https://zuul.opendev.org/t/openstack/build/652843f2641e47d781264a815a14894d > : POST_FAILURE in 2m 54s > > During the release job for ansible-role-redhat-subscription 1.1.1, twine > upload to PyPI failed with: > > HTTPError: 400 Bad Request from https://upload.pypi.org/legacy/ > The description failed to render in the default format of > reStructuredText. See https://pypi.org/help/#description-content-type > for more information. > > It's weird because it looks like this was addressed about a year ago, > and nothing significant changed in that area in the months following > 1.1.0 release. > > Hi Thierry, thanks for the update on that I would have missed it if you didn't send this mail. I am a bit confused though as you mentioned 1.1.0 here do you mean this is something to do with the ansible-role-redhat-subscription repo itself? > Current status: > Tag was pushed OK > No tarball upload > No PyPI upload > > Once the issue is fixed, the tag reference should be reenqueued. > > Indeed I see the tag is pushed OK https://opendev.org/openstack/ansible-role-redhat-subscription/src/tag/1.1.1 - so with respect to the pypi upload is there something for us to investigate or are we waiting on a rerun of the job? thanks, marios > -- > Thierry Carrez (ttx) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry at openstack.org Thu Nov 5 13:23:02 2020 From: thierry at openstack.org (Thierry Carrez) Date: Thu, 5 Nov 2020 14:23:02 +0100 Subject: [Release-job-failures] Release of openstack/ansible-role-redhat-subscription for ref refs/tags/1.1.1 failed In-Reply-To: References: Message-ID: <642745d9-ca22-3830-c9d1-36f3e97a458d@openstack.org> Marios Andreou wrote: > thanks for the update on that I would have missed it if you didn't send > this mail. This is actually in reaction to a release job failure email that I received, so that we discuss the solution on the list. There was no prior email on the topic. > I am a bit confused though as you mentioned 1.1.0 here do you > mean this is something to do with the ansible-role-redhat-subscription > repo itself? The failure is linked to the content of the repository: basically, PyPI is rejecting how the README is specified. So it will likely require a patch to ansible-role-redhat-subscription itself, in which case we'd push a new tag (1.1.2). That said, it's unclear what the problem is, as the same problem was fixed[1] a year ago already and nothing really changed since the (successful) 1.1.0 publication. We'll explore more and let you know if there is anything you can help with :) [1] https://opendev.org/openstack/ansible-role-redhat-subscription/commit/fceb51c66eb343a7cd20891da8728c65ff703ce7 -- Thierry Carrez (ttx) From satish.txt at gmail.com Thu Nov 5 13:58:39 2020 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 5 Nov 2020 08:58:39 -0500 Subject: ovs-dpdk bonding question Message-ID: Folks, I have a compute node with only 2x10G port in that case, how do I configure ovs-dpdk with bonding support? I can understand if i have more than 2 nic ports then i can make one of nic port to management but in my case i have only two. Does that mean I can't utilize bonding features, is that true? How do other folks deal with this kind of scenario? (my deployment tool is openstack-ansible) ~S From whayutin at redhat.com Thu Nov 5 14:51:12 2020 From: whayutin at redhat.com (Wesley Hayutin) Date: Thu, 5 Nov 2020 07:51:12 -0700 Subject: [tripleo][ci] ubi-8:3 has broken all centos-8 tripleo jobs Message-ID: Greetings, Bug: https://bugs.launchpad.net/tripleo/+bug/1902846 Patch: https://review.opendev.org/#/c/761463 Status: RED Thanks to Sagi and Sandeep ( ruck / rovers ) the issue was caught yesterday. Few iterations on where and how to pin this back to a working ubi-8 image for containers builds. We are confident the current patch will set things back to working. Context: https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image CentOS / RHEL ecosystem are not quite in sync yet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marios at redhat.com Thu Nov 5 15:17:26 2020 From: marios at redhat.com (Marios Andreou) Date: Thu, 5 Nov 2020 17:17:26 +0200 Subject: [Release-job-failures] Release of openstack/ansible-role-redhat-subscription for ref refs/tags/1.1.1 failed In-Reply-To: <642745d9-ca22-3830-c9d1-36f3e97a458d@openstack.org> References: <642745d9-ca22-3830-c9d1-36f3e97a458d@openstack.org> Message-ID: On Thu, Nov 5, 2020 at 3:24 PM Thierry Carrez wrote: > Marios Andreou wrote: > > thanks for the update on that I would have missed it if you didn't send > > this mail. > > This is actually in reaction to a release job failure email that I > received, so that we discuss the solution on the list. There was no > prior email on the topic. > > > I am a bit confused though as you mentioned 1.1.0 here do you > > mean this is something to do with the ansible-role-redhat-subscription > > repo itself? > > The failure is linked to the content of the repository: basically, PyPI > is rejecting how the README is specified. So it will likely require a > patch to ansible-role-redhat-subscription itself, in which case we'd > push a new tag (1.1.2). > > That said, it's unclear what the problem is, as the same problem was > fixed[1] a year ago already and nothing really changed since the > (successful) 1.1.0 publication. We'll explore more and let you know if > there is anything you can help with :) > > ack! Thank you much clearer for me now. If there is an update required then no problem we can address that and update with a newer tag > [1] > > https://opendev.org/openstack/ansible-role-redhat-subscription/commit/fceb51c66eb343a7cd20891da8728c65ff703ce7 > > -- > Thierry Carrez (ttx) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Thu Nov 5 15:33:04 2020 From: hberaud at redhat.com (Herve Beraud) Date: Thu, 5 Nov 2020 16:33:04 +0100 Subject: [Release-job-failures] Release of openstack/ansible-role-redhat-subscription for ref refs/tags/1.1.1 failed In-Reply-To: References: <642745d9-ca22-3830-c9d1-36f3e97a458d@openstack.org> Message-ID: I confirm the markdown issue was fixed 1 year ago [1] by myself and since 3 new versions of ansible-role-redhat-subscription have been released [2]. The markdown fix is embedded in the three releases: $ git tag --contains fceb51c66e 1.0.4 1.1.0 1.1.1 2 releases was successfully uploaded to pypi: - https://pypi.org/project/ansible-role-redhat-subscription/1.1.0/ - https://pypi.org/project/ansible-role-redhat-subscription/1.0.4/ I saw a couple of changes in your README and they seem to mix markdown and restructuredText [3], maybe it could explain this issue but these changes are also in previous versions: $ git tag --contains 0949f34ffb 1.0.3 1.0.4 1.1.0 1.1.1 Maybe pypa introduced more strict checks on their side since our last release... I tried to generate a PKG-INFO locally and everything seems ok. Also I didn't see any new bugs that seem related to this issue on the pypa side [4]. [1] https://opendev.org/openstack/ansible-role-redhat-subscription/commit/fceb51c66eb343a7cd20891da8728c65ff703ce7 [2] https://opendev.org/openstack/releases/commits/branch/master/deliverables/_independent/ansible-role-redhat-subscription.yaml [3] https://opendev.org/openstack/ansible-role-redhat-subscription/commit/0949f34ffb10e51787e824b00f0b5ae69592cdda [4] https://github.com/search?q=org%3Apypa+The+description+failed+to+render+in+the+default+format+of+reStructuredText&type=issues Le jeu. 5 nov. 2020 à 14:26, Thierry Carrez a écrit : > Marios Andreou wrote: > > thanks for the update on that I would have missed it if you didn't send > > this mail. > > This is actually in reaction to a release job failure email that I > received, so that we discuss the solution on the list. There was no > prior email on the topic. > > > I am a bit confused though as you mentioned 1.1.0 here do you > > mean this is something to do with the ansible-role-redhat-subscription > > repo itself? > > The failure is linked to the content of the repository: basically, PyPI > is rejecting how the README is specified. So it will likely require a > patch to ansible-role-redhat-subscription itself, in which case we'd > push a new tag (1.1.2). > > That said, it's unclear what the problem is, as the same problem was > fixed[1] a year ago already and nothing really changed since the > (successful) 1.1.0 publication. We'll explore more and let you know if > there is anything you can help with :) > > [1] > > https://opendev.org/openstack/ansible-role-redhat-subscription/commit/fceb51c66eb343a7cd20891da8728c65ff703ce7 > > -- > Thierry Carrez (ttx) > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- Le jeu. 5 nov. 2020 à 16:21, Marios Andreou a écrit : > > > On Thu, Nov 5, 2020 at 3:24 PM Thierry Carrez > wrote: > >> Marios Andreou wrote: >> > thanks for the update on that I would have missed it if you didn't send >> > this mail. >> >> This is actually in reaction to a release job failure email that I >> received, so that we discuss the solution on the list. There was no >> prior email on the topic. >> >> > I am a bit confused though as you mentioned 1.1.0 here do you >> > mean this is something to do with the ansible-role-redhat-subscription >> > repo itself? >> >> The failure is linked to the content of the repository: basically, PyPI >> is rejecting how the README is specified. So it will likely require a >> patch to ansible-role-redhat-subscription itself, in which case we'd >> push a new tag (1.1.2). >> >> That said, it's unclear what the problem is, as the same problem was >> fixed[1] a year ago already and nothing really changed since the >> (successful) 1.1.0 publication. We'll explore more and let you know if >> there is anything you can help with :) >> >> > ack! Thank you much clearer for me now. If there is an update required > then no problem we can address that and update with a newer tag > > > > >> [1] >> >> https://opendev.org/openstack/ansible-role-redhat-subscription/commit/fceb51c66eb343a7cd20891da8728c65ff703ce7 >> >> -- >> Thierry Carrez (ttx) >> >> -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From pub.virtualization at gmail.com Thu Nov 5 05:28:39 2020 From: pub.virtualization at gmail.com (Henry lol) Date: Thu, 5 Nov 2020 14:28:39 +0900 Subject: Question about the instance snapshot Message-ID: Hello, everyone I'm wondering whether the snapshot from the instance saves all disks attached to the instance or only the main(=first) disk, because I can't find any clear description for it. If the latter is true, should I detach all disks except for the main from the instance before taking a snapshot, and why doesn't it support all attached disks? Thanks Sincerely, -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali74.ebrahimpour at gmail.com Thu Nov 5 09:09:39 2020 From: ali74.ebrahimpour at gmail.com (Ali Ebrahimpour) Date: Thu, 5 Nov 2020 12:39:39 +0330 Subject: freezer Message-ID: hi i recently install the freezer api and i have problem with using it if run this command: freezer-agent --debug --action backup --nova-inst-id a143d11d-fa27-4716-9795-e03b4e601df4 --storage local --container /tmp/ali --backup-name test --mode nova --engine nova --no-incremental true --log-file a.log --consistency-check and freezer api doesn't work current and error with: Engine error: a bytes-like object is required, not 'str' Engine error: Forced stop Adn attach the log please help me ! thank you for attention -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: a.log Type: application/octet-stream Size: 90423 bytes Desc: not available URL: From ali74.ebrahimpour at gmail.com Thu Nov 5 09:12:06 2020 From: ali74.ebrahimpour at gmail.com (Ali Ebrahimpour) Date: Thu, 5 Nov 2020 12:42:06 +0330 Subject: Fwd: freezer In-Reply-To: References: Message-ID: hi i recently install the freezer api and i have problem with using it if run this command: freezer-agent --debug --action backup --nova-inst-id a143d11d-fa27-4716-9795-e03b4e601df4 --storage local --container /tmp/ali --backup-name test --mode nova --engine nova --no-incremental true --log-file a.log --consistency-check and freezer api doesn't work current and error with: Engine error: a bytes-like object is required, not 'str' Engine error: Forced stop Adn attach the log please help me ! thank you for attention -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: a.log Type: application/octet-stream Size: 90423 bytes Desc: not available URL: From whayutin at redhat.com Thu Nov 5 19:31:35 2020 From: whayutin at redhat.com (Wesley Hayutin) Date: Thu, 5 Nov 2020 12:31:35 -0700 Subject: [tripleo][ci] ubi-8:3 has broken all centos-8 tripleo jobs In-Reply-To: References: Message-ID: On Thu, Nov 5, 2020 at 7:51 AM Wesley Hayutin wrote: > Greetings, > > Bug: > https://bugs.launchpad.net/tripleo/+bug/1902846 > > Patch: > https://review.opendev.org/#/c/761463 > > Status: RED > Thanks to Sagi and Sandeep ( ruck / rovers ) the issue was caught > yesterday. Few iterations on where and how to pin this back to a working > ubi-8 image for containers builds. We are confident the current patch will > set things back to working. > > Context: > https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image > CentOS / RHEL ecosystem are not quite in sync yet. > OK.. the patch has merged. We'll be monitoring the gate and see if we see anything else come up. As usual look at #tripleo for status... going to yellow. DON'T recheck the world yet -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Thu Nov 5 20:35:47 2020 From: skaplons at redhat.com (Slawek Kaplonski) Date: Thu, 05 Nov 2020 21:35:47 +0100 Subject: [neutron]Drivers meeting 06.11.2020 - cancelled Message-ID: <3846730.JagzSZ0HJ7@p1> Hi, We don't have any new RFEs to discuss so lets cancel tomorrow's drivers meeting. There is one fresh RFE [1] but we discussed that durig the PTG so now lets wait for proposed spec with more details and we will get back to discussion about approval of it in the drivers meeting in next weeks. Have a great weekend. [1] https://bugs.launchpad.net/neutron/+bug/1900934 -- Slawek Kaplonski Principal Software Engineer Red Hat From rafaelweingartner at gmail.com Thu Nov 5 21:05:47 2020 From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=) Date: Thu, 5 Nov 2020 18:05:47 -0300 Subject: [neutron]Drivers meeting 06.11.2020 - cancelled In-Reply-To: <3846730.JagzSZ0HJ7@p1> References: <3846730.JagzSZ0HJ7@p1> Message-ID: I had a topic for this meeting. I wanted to ask about the spec https://review.opendev.org/#/c/739549/. Do we need other meetings to discuss it? Or, is the spec and the discussions we had there enough? We wanted to see it going out in Wallaby release. On Thu, Nov 5, 2020 at 5:39 PM Slawek Kaplonski wrote: > Hi, > > We don't have any new RFEs to discuss so lets cancel tomorrow's drivers > meeting. > There is one fresh RFE [1] but we discussed that durig the PTG so now lets > wait for proposed spec with more details and we will get back to > discussion > about approval of it in the drivers meeting in next weeks. > Have a great weekend. > > [1] https://bugs.launchpad.net/neutron/+bug/1900934 > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat > > > > -- Rafael Weingärtner -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Thu Nov 5 21:49:50 2020 From: smooney at redhat.com (Sean Mooney) Date: Thu, 05 Nov 2020 21:49:50 +0000 Subject: Fwd: freezer In-Reply-To: References: Message-ID: <859b373263dd608c04fae208a89b038e1cb7efc9.camel@redhat.com> On Thu, 2020-11-05 at 12:42 +0330, Ali Ebrahimpour wrote: > hi i recently install the freezer api and i have problem with using it > if run this command: > freezer-agent --debug --action backup --nova-inst-id > a143d11d-fa27-4716-9795-e03b4e601df4 --storage local --container /tmp/ali > --backup-name test  --mode nova --engine nova --no-incremental true >  --log-file a.log --consistency-check > > and freezer api doesn't work current and error with: > Engine error: a bytes-like object is required, not 'str' >  Engine error: Forced stop that looks like a python 3 issue im not sure how active it still is but it looks like its an issue between text string and byte strings > > Adn attach the log > please help me ! > > thank you for attention From haleyb.dev at gmail.com Fri Nov 6 03:15:59 2020 From: haleyb.dev at gmail.com (Brian Haley) Date: Thu, 5 Nov 2020 22:15:59 -0500 Subject: [neutron]Drivers meeting 06.11.2020 - cancelled In-Reply-To: References: <3846730.JagzSZ0HJ7@p1> Message-ID: <4adbaaa5-f795-0537-f26e-5547bad5d978@gmail.com> On 11/5/20 4:05 PM, Rafael Weingärtner wrote: > I had a topic for this meeting. I wanted to ask about the spec > https://review.opendev.org/#/c/739549/. > Do we need other meetings to discuss it? Or, is the spec  and the > discussions we had there enough? We wanted to see it going out in > Wallaby release. From https://bugs.launchpad.net/neutron/+bug/1885921/comments/4 this RFE was approved. I see you just had to re-target it to Wallaby, which is fine, I think we can continue any further discussions in the reviews. -Brian > On Thu, Nov 5, 2020 at 5:39 PM Slawek Kaplonski > wrote: > > Hi, > > We don't have any new RFEs to discuss so lets cancel tomorrow's drivers > meeting. > There is one fresh RFE [1] but we discussed that durig the PTG so > now lets > wait for proposed spec with more details and we will get back to > discussion > about approval of it in the drivers meeting in next weeks. > Have a great weekend. > > [1] https://bugs.launchpad.net/neutron/+bug/1900934 > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat > > > > > > -- > Rafael Weingärtner From walsh277072 at gmail.com Fri Nov 6 05:20:30 2020 From: walsh277072 at gmail.com (WALSH CHANG) Date: Fri, 6 Nov 2020 05:20:30 +0000 Subject: [cinder][ceilometer][heat][instances] Installation Problems Message-ID: To whom it may concern, I am new to openstack, I got several errors when I installed the service followed by the installation guide. My openstack version : stein Ubuntu 18.0.4 1. Cinder-api is in /usr/bin/cinder-api, but when I type service cinder-api status, it shows Unit cinder-api.service could not be found. 2. Ceilometer and Heat tab didn't show in the Dashboard. 3. I was trying to launch an instance, but I got the status error and I tried to delete, but the instances can not be deleted. And I used nova force-delete instance-id, the error message is ERROR (ClientException): Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. (HTTP 500) (Request-ID: req-e6c0d966-c7ec-4f20-8e9f-c788018a8d81) I explored the openstack installation myself, just wondering if there is any online hands-on training or course that I can enroll in? Thanks. Kind regards, Walsh -------------- next part -------------- An HTML attachment was scrubbed... URL: From pramchan at yahoo.com Fri Nov 6 06:47:35 2020 From: pramchan at yahoo.com (prakash RAMCHANDRAN) Date: Fri, 6 Nov 2020 06:47:35 +0000 (UTC) Subject: [openstack][InteropWG] : Interop weekly Friday call In-Reply-To: <1757fc3ee30.eea7e45388786.4328160222881040161@ghanshyammann.com> References: <1295138775.3349683.1603717569398.ref@mail.yahoo.com> <1295138775.3349683.1603717569398@mail.yahoo.com> <1791751856.3420249.1603726712148@mail.yahoo.com> <352076537.476027.1604015407570@mail.yahoo.com> <1829403956.43078.1604102260422@mail.yahoo.com> <1757fc3ee30.eea7e45388786.4328160222881040161@ghanshyammann.com> Message-ID: <1676177545.2373771.1604645255017@mail.yahoo.com> Hi all,Thanks Ghanshyam we may no impact based on zuul v3 for testing using tempest. If we submit a new guideline for 2020.10.json where will I see the patch under https://devops.org/osf/interior or patch?osf/interop  Let's ho over the call tomorrow 10 AM PST.Please join and add your topics to https://etherpad.opendev.org/p/interop The meet pad link for call is on eitherpad. ThanksPrakash Sent from Yahoo Mail on Android On Sat, Oct 31, 2020 at 10:45 AM, Ghanshyam Mann wrote: ---- On Fri, 30 Oct 2020 18:57:40 -0500 prakash RAMCHANDRAN wrote ---- >        Hi all, > We have few major Tasks  to elevate Interop WG to enable OpenStack + Open Infrastructure Branding and Logo Programs: > 1. https://opendev.org/osf/interop/src/branch/master/2020.06.json (To patch and update to 2020.10.json)All core module owners of Integrated OpenStack please respond before next Friday  Nov 6 -Interop WG call on meetpad > Interop Working Group - Weekly Friday 10-11 AM or UTC 17-18  (Next on Nov 6 & 13th)Lnink: https://meetpad.opendev.org/Interop-WG-weekly-meeting > Checklist for PTLs (core - keystone, glance, nova, neutron, cinder & swift) and add-ons (heat & designate) > 1. Did the Victoria switch for Jenkins to Zuul V3 and  move to new Ubuntu Focal impact your  DevStack and Tempesting module  feature testing in any way  for Interop? It is moved from zuulv2 native jobs to zuulv3 native and Ubuntu Bionic to Ubuntu Focal which basically are only testing framework side updates not on any user facing interface updates so it will not impact any interop way. -gmann > 2. Pease check  https://opendev.org/osf/interop/src/branch/master/2020.06.json#L72We will drop stein and add wallaby, hence train release notes will be the base line for feature retention and compliance baseline  testing > Please verify what are the changes you may need for Victoria cycle for Logo program for your modules list all"required": [] > "advisory": [], > "deprecated": [], > "removed": [] > > 3. Reply by email the changes expected for us the review based on your Victoria release notes or add notes to https://releases.openstack.org/victoria/?_ga=2.174650977.277942436.1604012691-802386709.1603466376 > > >  4. Discussions on Manila - Need Volunteer 5. Discussions on Ironic - Need Volunteers 6. Discussion on future Kata GoLang  -  Kata (with tempest vs k8s test tools  or  https://onsi.github.io/ginkgo/ +  Airship, Starlingx, Zuul on infralab ?) - Need Volunteers > > ThanksPrakashFor Interop WG > ==================================================================================================================                                                            >                >                >                        Hi all, > We have two sessions one at  13 UTC ( 6 AM PDT) and 16 UTC (9 AM PDT) > Based on our interactions and collaborations - Manila team met and I could not attend their call but here is the link to their efforts: > https://etherpad.opendev.org/p/wallaby-ptg-manila-interop >  We have 4 items to cover and seeking Volunteers for possible Manila & kubernetes Kata + RUNC based Container compliance (GoLang Must) > Also we are planning to introduce GoLang based Refstak/Tempest if there are volunteers ready to work with QA team (Gmann). > Thus we can finish in 1 session at 13 UTC and plan to  cancel the second session at 16 UTC.====================================================================================================Your comments > > > > > ======================================================================================================See you for Interop and add any comments above > ThanksPrakashFor Interop WG >                                                                                On Monday, October 26, 2020, 08:38:32 AM PDT, prakash RAMCHANDRAN wrote:                                >                >                        Hi all > My apology on the delayed start and here is the items we went over on first session. > Refer : https://etherpad.opendev.org/p/interop-wallaby-ptg (Monday 10/26 recorded the meeting for everyone to see, its cloud recording and will know from PTG hosts where they have that?) > Summary:1. Plan to Complete Victoria guidelines specs  for interop in 2-6 weeks depending on adding new  [OpenStack Powered File System Branding as Add-on Program] >    - last Ussuri  guidelines are at https://opendev.org/osf/interop/src/branch/master/2020.06.json > > > > New one will be 2020.10.json to be added >    - For existing integrated modules  [ Core OpenStack services including identity, compute, networking, block storage, and object storage ]    - for two existing add-ons [Orchestration (heat) , DNS (designate) "Not a core capability, add-on program is available"    - This is for Manila Filesystem add-on OpenDev Etherpad "Not a core capability, add-on program to be made available" >  OpenDev Etherpad > >  >  >  > > > > > We have one more opportunity  on 10/30 slot at the end of PTG if BMaaS (Ironic) if Julia has any proposals, besides  (Open Infra Kata + Docker) Container has additional proposal community is working on.    Look forward to seeing you all on October 30 as what the Road-map will look like for 2020 and 2021 going forward. > ThanksPrakash > >                                                                                On Monday, October 26, 2020, 06:09:00 AM PDT, Goutham Pacha Ravi wrote:                                >                >                Hi Prakash, > > We're here: https://zoom.us/j/92649902134?pwd=a01aMXl6ZlNEZDlsMjJMTGNMVUp1UT09 > > On Mon, Oct 26, 2020 at 6:06 AM prakash RAMCHANDRAN wrote: > https://meetpad.opendev.org/Interop-WG-weekly-meeting >                                                            -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at est.tech Fri Nov 6 08:29:56 2020 From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer) Date: Fri, 06 Nov 2020 09:29:56 +0100 Subject: [nova] Wallaby spec review day Message-ID: Hi, Wallaby Milestone 1 is four weeks from now. As Sylvain raised on the weekly meeting it is a good time to have a spec review day somewhere before M1. So I'm proposing 17th of November as spec review day. Let me know if it what you think. Cheers, gibi From Cyrille.CARTIER at antemeta.fr Fri Nov 6 08:38:23 2020 From: Cyrille.CARTIER at antemeta.fr (Cyrille CARTIER) Date: Fri, 6 Nov 2020 08:38:23 +0000 Subject: Fwd: freezer In-Reply-To: <859b373263dd608c04fae208a89b038e1cb7efc9.camel@redhat.com> References: <859b373263dd608c04fae208a89b038e1cb7efc9.camel@redhat.com> Message-ID: <6cb413b63f30445b9e776f0c2e0ab153@GUYMAIL02.antemeta.net> Hi Ali, Which openstack version do you use ? I have a similar problem on my Train plateform (deployed by kolla-ansible), using freezer-scheduler. There are many commit for py3 correction for Ussuri and Victoria branch, in Git repository [1]. Did you try these version? I have already post the problem on StoryBoard [2] and Launchpad [3]. -----Message d'origine----- Objet : Re: Fwd: freezer On Thu, 2020-11-05 at 12:42 +0330, Ali Ebrahimpour wrote: > hi i recently install the freezer api and i have problem with using it > if run this command: > freezer-agent --debug --action backup --nova-inst-id > a143d11d-fa27-4716-9795-e03b4e601df4 --storage local --container > /tmp/ali --backup-name test  --mode nova --engine nova > --no-incremental true >  --log-file a.log --consistency-check > > and freezer api doesn't work current and error with: > Engine error: a bytes-like object is required, not 'str' >  Engine error: Forced stop that looks like a python 3 issue im not sure how active it still is but it looks like its an issue between text string and byte strings > > Adn attach the log > please help me ! > > thank you for attention [1]: https://opendev.org/openstack/freezer [2]: https://storyboard.openstack.org/#!/project/openstack/freezer [3]: https://bugs.launchpad.net/freezer/+bug/1901179 Cyrille From rafaelweingartner at gmail.com Fri Nov 6 09:56:35 2020 From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=) Date: Fri, 6 Nov 2020 06:56:35 -0300 Subject: [neutron]Drivers meeting 06.11.2020 - cancelled In-Reply-To: <4adbaaa5-f795-0537-f26e-5547bad5d978@gmail.com> References: <3846730.JagzSZ0HJ7@p1> <4adbaaa5-f795-0537-f26e-5547bad5d978@gmail.com> Message-ID: Great, thanks! Em sex, 6 de nov de 2020 00:16, Brian Haley escreveu: > On 11/5/20 4:05 PM, Rafael Weingärtner wrote: > > I had a topic for this meeting. I wanted to ask about the spec > > https://review.opendev.org/#/c/739549/. > > Do we need other meetings to discuss it? Or, is the spec and the > > discussions we had there enough? We wanted to see it going out in > > Wallaby release. > > From https://bugs.launchpad.net/neutron/+bug/1885921/comments/4 this > RFE was approved. I see you just had to re-target it to Wallaby, which > is fine, I think we can continue any further discussions in the reviews. > > -Brian > > > On Thu, Nov 5, 2020 at 5:39 PM Slawek Kaplonski > > wrote: > > > > Hi, > > > > We don't have any new RFEs to discuss so lets cancel tomorrow's > drivers > > meeting. > > There is one fresh RFE [1] but we discussed that durig the PTG so > > now lets > > wait for proposed spec with more details and we will get back to > > discussion > > about approval of it in the drivers meeting in next weeks. > > Have a great weekend. > > > > [1] https://bugs.launchpad.net/neutron/+bug/1900934 > > > > -- > > Slawek Kaplonski > > Principal Software Engineer > > Red Hat > > > > > > > > > > > > -- > > Rafael Weingärtner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Fri Nov 6 10:02:32 2020 From: hberaud at redhat.com (Herve Beraud) Date: Fri, 6 Nov 2020 11:02:32 +0100 Subject: [oslo][release] Oslo's Transition To Independent In-Reply-To: <4a9dc3ba-ef77-fdfd-2729-b7cb6357e3ed@nemebean.com> References: <4a9dc3ba-ef77-fdfd-2729-b7cb6357e3ed@nemebean.com> Message-ID: First, thanks for your answer. Le mer. 4 nov. 2020 à 15:50, Ben Nemec a écrit : > > > On 11/4/20 7:31 AM, Herve Beraud wrote: > > Greetings, > > > > Is it time for us to move some parts of Oslo to the independent release > > model [1]? > > > > I think we could consider Oslo world is mostly stable enough to answer > > yes to the previous question. > > > > However, the goal of this email is to trigger the debat and see which > > deliverables could be transitioned to the independent model. > > > > Do we need to expect that major changes will happen within Oslo and who > > could warrant to continue to follow cycle-with-intermediary model [2]? > > I would hesitate to try to predict the future on what will see major > changes and what won't. I would prefer to look at this more from the > perspective of what Oslo libraries are tied to the OpenStack version. > For example, I don't think oslo.messaging should be moved to > independent. It's important that RPC has a sane version to version > upgrade path, and the easiest way to ensure that is to keep it on the > regular cycle release schedule. The same goes for other libraries too: > oslo.versionedobjects, oslo.policy, oslo.service, oslo.db, possibly also > things like oslo.config and oslo.context (I suspect contexts need to be > release-specific, but maybe someone from a consuming project can weigh > in). Even oslo.serialization could have upgrade impacts if it is being > used to serialize internal data in a service. > Agreed, the goal here isn't to try to move everything to the independent model but more to identify which projects could be eligible for this switch. I strongly agree that the previous list of projects that you quote should stay binded to openstack cycles and should continue to rely on stable branches. These kinds of projects and also openstack's services are strongly tied to backends, their version, and available APIs and so to openstack's series, so they must remain linked to them. > That said, many of the others can probably be moved. oslo.i18n and > oslo.upgradecheck are both pretty stable at this point and not really > tied to a specific release. As long as we're responsible with any future > changes to them it should be pretty safe to make them independent. > Agreed. > This does raise a question though: Are the benefits of going independent > with the release model sufficient to justify splitting the release > models of the Oslo projects? I assume the motivation is to avoid having > to do as many backports of bug fixes, but if we're mostly doing this > with low-volume, stable projects does it gain us that much? > Yes, you're right, it could help us to reduce our needed maintenance and so our Oslo's activity in general. Indeed, about 35 projects are hosted by Oslo and concerning the active maintainers the trend isn't on the rise. So reducing the number of stable branches to maintain could benefit us, and it could be done by moving projects to an independent model. > > I guess I don't have a strong opinion one way or another on this yet, > and would defer to our release liaisons if they want to go one way or > other other. Hopefully this provides some things to think about though. > Yes you provided interesting observations, thanks. It could be interesting to get feedback from other cores. > -Ben > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From ionut at fleio.com Fri Nov 6 10:33:16 2020 From: ionut at fleio.com (Ionut Biru) Date: Fri, 6 Nov 2020 12:33:16 +0200 Subject: [magnum] heat-container-agent:victoria-dev Message-ID: Hi, 20 days ago the image was updated and now all clusters fail to deploy because it cannot find /usr/bin/kubectl, i think. /usr/bin/kubectl apply -f /srv/magnum/kubernetes/manifests/calico-deploy.yaml --namespace=kube-system Some services are installed using full path instead of simply kubectl. Should the image be fixed or reverted the changes to old revision or we should just fix the scripts? -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ionut at fleio.com Fri Nov 6 10:33:37 2020 From: ionut at fleio.com (Ionut Biru) Date: Fri, 6 Nov 2020 12:33:37 +0200 Subject: [magnum] heat-container-agent:victoria-dev In-Reply-To: References: Message-ID: I wanted to say, 20 hours ago instead of days. On Fri, Nov 6, 2020 at 12:33 PM Ionut Biru wrote: > Hi, > > 20 days ago the image was updated and now all clusters fail to deploy > because it cannot find > /usr/bin/kubectl, i think. > > /usr/bin/kubectl apply -f > /srv/magnum/kubernetes/manifests/calico-deploy.yaml --namespace=kube-system > > Some services are installed using full path instead of simply kubectl. > > Should the image be fixed or reverted the changes to old revision or we > should just fix the scripts? > > -- > Ionut Biru - https://fleio.com > -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From strigazi at gmail.com Fri Nov 6 10:43:15 2020 From: strigazi at gmail.com (Spyros Trigazis) Date: Fri, 6 Nov 2020 11:43:15 +0100 Subject: [magnum] heat-container-agent:victoria-dev In-Reply-To: References: Message-ID: Am I missing something? It is there. Spyros ubuntu at str-focal-2xlarge-01:~$ docker run -it --entrypoint /usr/bin/kubectl openstackmagnum/heat-container-agent:victoria-dev version --client --short Client Version: v1.18.2 ubuntu at str-focal-2xlarge-01:~$ docker run -it --entrypoint /usr/bin/kubectl openstackmagnum/heat-container-agent at sha256:0f354341b1970b7dacd9825a1c7585bae5495842416123941965574374922b51 version --client --short Client Version: v1.18.2 On Fri, Nov 6, 2020 at 11:33 AM Ionut Biru wrote: > I wanted to say, 20 hours ago instead of days. > > On Fri, Nov 6, 2020 at 12:33 PM Ionut Biru wrote: > >> Hi, >> >> 20 days ago the image was updated and now all clusters fail to deploy >> because it cannot find >> /usr/bin/kubectl, i think. >> >> /usr/bin/kubectl apply -f >> /srv/magnum/kubernetes/manifests/calico-deploy.yaml --namespace=kube-system >> >> Some services are installed using full path instead of simply kubectl. >> >> Should the image be fixed or reverted the changes to old revision or we >> should just fix the scripts? >> >> -- >> Ionut Biru - https://fleio.com >> > > > -- > Ionut Biru - https://fleio.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ionut at fleio.com Fri Nov 6 11:01:31 2020 From: ionut at fleio.com (Ionut Biru) Date: Fri, 6 Nov 2020 13:01:31 +0200 Subject: [magnum] heat-container-agent:victoria-dev In-Reply-To: References: Message-ID: Hi, Not sure if because kubectl is not found but here are the logs, I cannot figure out why it is not working with the new heat image. journalctl https://paste.xinu.at/jsA/ heat-config master https://paste.xinu.at/pEz/ heat-config master cluster config https://paste.xinu.at/K85ZY5/ [root at cluster001-7dby23lm6ods-master-0 heat-config-script]# kubectl get pods --all-namespaces No resources found [root at cluster001-7dby23lm6ods-master-0 heat-config-script]# kubectl get all --all-namespaces NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE default service/kubernetes ClusterIP 10.254.0.1 443/TCP 36m It fails to deploy and I don't have any services configured. On Fri, Nov 6, 2020 at 12:43 PM Spyros Trigazis wrote: > Am I missing something? It is there. > > Spyros > > ubuntu at str-focal-2xlarge-01:~$ docker run -it --entrypoint > /usr/bin/kubectl openstackmagnum/heat-container-agent:victoria-dev version > --client --short > Client Version: v1.18.2 > ubuntu at str-focal-2xlarge-01:~$ docker run -it --entrypoint > /usr/bin/kubectl openstackmagnum/heat-container-agent at sha256:0f354341b1970b7dacd9825a1c7585bae5495842416123941965574374922b51 > version --client --short > Client Version: v1.18.2 > > On Fri, Nov 6, 2020 at 11:33 AM Ionut Biru wrote: > >> I wanted to say, 20 hours ago instead of days. >> >> On Fri, Nov 6, 2020 at 12:33 PM Ionut Biru wrote: >> >>> Hi, >>> >>> 20 days ago the image was updated and now all clusters fail to deploy >>> because it cannot find >>> /usr/bin/kubectl, i think. >>> >>> /usr/bin/kubectl apply -f >>> /srv/magnum/kubernetes/manifests/calico-deploy.yaml --namespace=kube-system >>> >>> Some services are installed using full path instead of simply kubectl. >>> >>> Should the image be fixed or reverted the changes to old revision or we >>> should just fix the scripts? >>> >>> -- >>> Ionut Biru - https://fleio.com >>> >> >> >> -- >> Ionut Biru - https://fleio.com >> > -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From strigazi at gmail.com Fri Nov 6 11:23:28 2020 From: strigazi at gmail.com (Spyros Trigazis) Date: Fri, 6 Nov 2020 12:23:28 +0100 Subject: [magnum] heat-container-agent:victoria-dev In-Reply-To: References: Message-ID: I see, this says kubectl misconfigured not missing. error: Missing or incomplete configuration info. Please point to an existing, complete config file: I guess you miss some patches: https://review.opendev.org/#/q/I15ef91bbec20a8037d47902225eabb3082579705 Try using an older image of the agent or take the patch above. Spyros On Fri, Nov 6, 2020 at 12:01 PM Ionut Biru wrote: > Hi, > > Not sure if because kubectl is not found but here are the logs, I cannot > figure out why it is not working with the new heat image. > > journalctl https://paste.xinu.at/jsA/ > heat-config master https://paste.xinu.at/pEz/ > heat-config master cluster config https://paste.xinu.at/K85ZY5/ > > [root at cluster001-7dby23lm6ods-master-0 heat-config-script]# kubectl get > pods --all-namespaces > No resources found > [root at cluster001-7dby23lm6ods-master-0 heat-config-script]# kubectl get > all --all-namespaces > NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP > PORT(S) AGE > default service/kubernetes ClusterIP 10.254.0.1 > 443/TCP 36m > > It fails to deploy and I don't have any services configured. > > On Fri, Nov 6, 2020 at 12:43 PM Spyros Trigazis > wrote: > >> Am I missing something? It is there. >> >> Spyros >> >> ubuntu at str-focal-2xlarge-01:~$ docker run -it --entrypoint >> /usr/bin/kubectl openstackmagnum/heat-container-agent:victoria-dev version >> --client --short >> Client Version: v1.18.2 >> ubuntu at str-focal-2xlarge-01:~$ docker run -it --entrypoint >> /usr/bin/kubectl openstackmagnum/heat-container-agent at sha256:0f354341b1970b7dacd9825a1c7585bae5495842416123941965574374922b51 >> version --client --short >> Client Version: v1.18.2 >> >> On Fri, Nov 6, 2020 at 11:33 AM Ionut Biru wrote: >> >>> I wanted to say, 20 hours ago instead of days. >>> >>> On Fri, Nov 6, 2020 at 12:33 PM Ionut Biru wrote: >>> >>>> Hi, >>>> >>>> 20 days ago the image was updated and now all clusters fail to deploy >>>> because it cannot find >>>> /usr/bin/kubectl, i think. >>>> >>>> /usr/bin/kubectl apply -f >>>> /srv/magnum/kubernetes/manifests/calico-deploy.yaml --namespace=kube-system >>>> >>>> Some services are installed using full path instead of simply kubectl. >>>> >>>> Should the image be fixed or reverted the changes to old revision or we >>>> should just fix the scripts? >>>> >>>> -- >>>> Ionut Biru - https://fleio.com >>>> >>> >>> >>> -- >>> Ionut Biru - https://fleio.com >>> >> > > -- > Ionut Biru - https://fleio.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ionut at fleio.com Fri Nov 6 11:34:44 2020 From: ionut at fleio.com (Ionut Biru) Date: Fri, 6 Nov 2020 13:34:44 +0200 Subject: [magnum] heat-container-agent:victoria-dev In-Reply-To: References: Message-ID: Hi, I'm using stable/victoria. It works fine with an older image. On Fri, Nov 6, 2020 at 1:28 PM Spyros Trigazis wrote: > I see, this says kubectl misconfigured not missing. > error: Missing or incomplete configuration info. Please point to an > existing, complete config file: > > I guess you miss some patches: > https://review.opendev.org/#/q/I15ef91bbec20a8037d47902225eabb3082579705 > > Try using an older image of the agent or take the patch above. > > Spyros > > On Fri, Nov 6, 2020 at 12:01 PM Ionut Biru wrote: > >> Hi, >> >> Not sure if because kubectl is not found but here are the logs, I cannot >> figure out why it is not working with the new heat image. >> >> journalctl https://paste.xinu.at/jsA/ >> heat-config master https://paste.xinu.at/pEz/ >> heat-config master cluster config https://paste.xinu.at/K85ZY5/ >> >> [root at cluster001-7dby23lm6ods-master-0 heat-config-script]# kubectl get >> pods --all-namespaces >> No resources found >> [root at cluster001-7dby23lm6ods-master-0 heat-config-script]# kubectl get >> all --all-namespaces >> NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP >> PORT(S) AGE >> default service/kubernetes ClusterIP 10.254.0.1 >> 443/TCP 36m >> >> It fails to deploy and I don't have any services configured. >> >> On Fri, Nov 6, 2020 at 12:43 PM Spyros Trigazis >> wrote: >> >>> Am I missing something? It is there. >>> >>> Spyros >>> >>> ubuntu at str-focal-2xlarge-01:~$ docker run -it --entrypoint >>> /usr/bin/kubectl openstackmagnum/heat-container-agent:victoria-dev version >>> --client --short >>> Client Version: v1.18.2 >>> ubuntu at str-focal-2xlarge-01:~$ docker run -it --entrypoint >>> /usr/bin/kubectl openstackmagnum/heat-container-agent at sha256:0f354341b1970b7dacd9825a1c7585bae5495842416123941965574374922b51 >>> version --client --short >>> Client Version: v1.18.2 >>> >>> On Fri, Nov 6, 2020 at 11:33 AM Ionut Biru wrote: >>> >>>> I wanted to say, 20 hours ago instead of days. >>>> >>>> On Fri, Nov 6, 2020 at 12:33 PM Ionut Biru wrote: >>>> >>>>> Hi, >>>>> >>>>> 20 days ago the image was updated and now all clusters fail to deploy >>>>> because it cannot find >>>>> /usr/bin/kubectl, i think. >>>>> >>>>> /usr/bin/kubectl apply -f >>>>> /srv/magnum/kubernetes/manifests/calico-deploy.yaml --namespace=kube-system >>>>> >>>>> Some services are installed using full path instead of simply kubectl. >>>>> >>>>> Should the image be fixed or reverted the changes to old revision or >>>>> we should just fix the scripts? >>>>> >>>>> -- >>>>> Ionut Biru - https://fleio.com >>>>> >>>> >>>> >>>> -- >>>> Ionut Biru - https://fleio.com >>>> >>> >> >> -- >> Ionut Biru - https://fleio.com >> > -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ionut at fleio.com Fri Nov 6 12:02:55 2020 From: ionut at fleio.com (Ionut Biru) Date: Fri, 6 Nov 2020 14:02:55 +0200 Subject: [magnum] heat-container-agent:victoria-dev In-Reply-To: References: Message-ID: Hi, I wonder if it is because the image is from fedora:rawhide and something is too new in there and breaks the flow? https://opendev.org/openstack/magnum/commit/1de7a6af5ee2b834360e3daba34adb6b908fa035 On Fri, Nov 6, 2020 at 1:34 PM Ionut Biru wrote: > Hi, > > I'm using stable/victoria. It works fine with an older image. > > On Fri, Nov 6, 2020 at 1:28 PM Spyros Trigazis wrote: > >> I see, this says kubectl misconfigured not missing. >> error: Missing or incomplete configuration info. Please point to an >> existing, complete config file: >> >> I guess you miss some patches: >> https://review.opendev.org/#/q/I15ef91bbec20a8037d47902225eabb3082579705 >> >> Try using an older image of the agent or take the patch above. >> >> Spyros >> >> On Fri, Nov 6, 2020 at 12:01 PM Ionut Biru wrote: >> >>> Hi, >>> >>> Not sure if because kubectl is not found but here are the logs, I cannot >>> figure out why it is not working with the new heat image. >>> >>> journalctl https://paste.xinu.at/jsA/ >>> heat-config master https://paste.xinu.at/pEz/ >>> heat-config master cluster config https://paste.xinu.at/K85ZY5/ >>> >>> [root at cluster001-7dby23lm6ods-master-0 heat-config-script]# kubectl get >>> pods --all-namespaces >>> No resources found >>> [root at cluster001-7dby23lm6ods-master-0 heat-config-script]# kubectl get >>> all --all-namespaces >>> NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP >>> PORT(S) AGE >>> default service/kubernetes ClusterIP 10.254.0.1 >>> 443/TCP 36m >>> >>> It fails to deploy and I don't have any services configured. >>> >>> On Fri, Nov 6, 2020 at 12:43 PM Spyros Trigazis >>> wrote: >>> >>>> Am I missing something? It is there. >>>> >>>> Spyros >>>> >>>> ubuntu at str-focal-2xlarge-01:~$ docker run -it --entrypoint >>>> /usr/bin/kubectl openstackmagnum/heat-container-agent:victoria-dev version >>>> --client --short >>>> Client Version: v1.18.2 >>>> ubuntu at str-focal-2xlarge-01:~$ docker run -it --entrypoint >>>> /usr/bin/kubectl openstackmagnum/heat-container-agent at sha256:0f354341b1970b7dacd9825a1c7585bae5495842416123941965574374922b51 >>>> version --client --short >>>> Client Version: v1.18.2 >>>> >>>> On Fri, Nov 6, 2020 at 11:33 AM Ionut Biru wrote: >>>> >>>>> I wanted to say, 20 hours ago instead of days. >>>>> >>>>> On Fri, Nov 6, 2020 at 12:33 PM Ionut Biru wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> 20 days ago the image was updated and now all clusters fail to deploy >>>>>> because it cannot find >>>>>> /usr/bin/kubectl, i think. >>>>>> >>>>>> /usr/bin/kubectl apply -f >>>>>> /srv/magnum/kubernetes/manifests/calico-deploy.yaml --namespace=kube-system >>>>>> >>>>>> Some services are installed using full path instead of simply kubectl. >>>>>> >>>>>> Should the image be fixed or reverted the changes to old revision or >>>>>> we should just fix the scripts? >>>>>> >>>>>> -- >>>>>> Ionut Biru - https://fleio.com >>>>>> >>>>> >>>>> >>>>> -- >>>>> Ionut Biru - https://fleio.com >>>>> >>>> >>> >>> -- >>> Ionut Biru - https://fleio.com >>> >> > > -- > Ionut Biru - https://fleio.com > -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From strigazi at gmail.com Fri Nov 6 12:36:36 2020 From: strigazi at gmail.com (Spyros Trigazis) Date: Fri, 6 Nov 2020 13:36:36 +0100 Subject: [magnum] heat-container-agent:victoria-dev In-Reply-To: References: Message-ID: Check if you have this patch deployed: https://review.opendev.org/#/q/I15ef91bbec20a8037d47902225eabb3082579705 On Fri, Nov 6, 2020 at 1:03 PM Ionut Biru wrote: > Hi, > > I wonder if it is because the image is from fedora:rawhide and something > is too new in there and breaks the flow? > > https://opendev.org/openstack/magnum/commit/1de7a6af5ee2b834360e3daba34adb6b908fa035 > > > On Fri, Nov 6, 2020 at 1:34 PM Ionut Biru wrote: > >> Hi, >> >> I'm using stable/victoria. It works fine with an older image. >> >> On Fri, Nov 6, 2020 at 1:28 PM Spyros Trigazis >> wrote: >> >>> I see, this says kubectl misconfigured not missing. >>> error: Missing or incomplete configuration info. Please point to an >>> existing, complete config file: >>> >>> I guess you miss some patches: >>> https://review.opendev.org/#/q/I15ef91bbec20a8037d47902225eabb3082579705 >>> >>> Try using an older image of the agent or take the patch above. >>> >>> Spyros >>> >>> On Fri, Nov 6, 2020 at 12:01 PM Ionut Biru wrote: >>> >>>> Hi, >>>> >>>> Not sure if because kubectl is not found but here are the logs, I >>>> cannot figure out why it is not working with the new heat image. >>>> >>>> journalctl https://paste.xinu.at/jsA/ >>>> heat-config master https://paste.xinu.at/pEz/ >>>> heat-config master cluster config https://paste.xinu.at/K85ZY5/ >>>> >>>> [root at cluster001-7dby23lm6ods-master-0 heat-config-script]# kubectl >>>> get pods --all-namespaces >>>> No resources found >>>> [root at cluster001-7dby23lm6ods-master-0 heat-config-script]# kubectl >>>> get all --all-namespaces >>>> NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP >>>> PORT(S) AGE >>>> default service/kubernetes ClusterIP 10.254.0.1 >>>> 443/TCP 36m >>>> >>>> It fails to deploy and I don't have any services configured. >>>> >>>> On Fri, Nov 6, 2020 at 12:43 PM Spyros Trigazis >>>> wrote: >>>> >>>>> Am I missing something? It is there. >>>>> >>>>> Spyros >>>>> >>>>> ubuntu at str-focal-2xlarge-01:~$ docker run -it --entrypoint >>>>> /usr/bin/kubectl openstackmagnum/heat-container-agent:victoria-dev version >>>>> --client --short >>>>> Client Version: v1.18.2 >>>>> ubuntu at str-focal-2xlarge-01:~$ docker run -it --entrypoint >>>>> /usr/bin/kubectl openstackmagnum/heat-container-agent at sha256:0f354341b1970b7dacd9825a1c7585bae5495842416123941965574374922b51 >>>>> version --client --short >>>>> Client Version: v1.18.2 >>>>> >>>>> On Fri, Nov 6, 2020 at 11:33 AM Ionut Biru wrote: >>>>> >>>>>> I wanted to say, 20 hours ago instead of days. >>>>>> >>>>>> On Fri, Nov 6, 2020 at 12:33 PM Ionut Biru wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> 20 days ago the image was updated and now all clusters fail to >>>>>>> deploy because it cannot find >>>>>>> /usr/bin/kubectl, i think. >>>>>>> >>>>>>> /usr/bin/kubectl apply -f >>>>>>> /srv/magnum/kubernetes/manifests/calico-deploy.yaml --namespace=kube-system >>>>>>> >>>>>>> Some services are installed using full path instead of simply >>>>>>> kubectl. >>>>>>> >>>>>>> Should the image be fixed or reverted the changes to old revision or >>>>>>> we should just fix the scripts? >>>>>>> >>>>>>> -- >>>>>>> Ionut Biru - https://fleio.com >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Ionut Biru - https://fleio.com >>>>>> >>>>> >>>> >>>> -- >>>> Ionut Biru - https://fleio.com >>>> >>> >> >> -- >> Ionut Biru - https://fleio.com >> > > > -- > Ionut Biru - https://fleio.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ionut at fleio.com Fri Nov 6 12:40:10 2020 From: ionut at fleio.com (Ionut Biru) Date: Fri, 6 Nov 2020 14:40:10 +0200 Subject: [magnum] heat-container-agent:victoria-dev In-Reply-To: References: Message-ID: Hi, yes, it's deployed: https://paste.xinu.at/pEz/#n855 On Fri, Nov 6, 2020 at 2:36 PM Spyros Trigazis wrote: > Check if you have this patch deployed: > https://review.opendev.org/#/q/I15ef91bbec20a8037d47902225eabb3082579705 > > On Fri, Nov 6, 2020 at 1:03 PM Ionut Biru wrote: > >> Hi, >> >> I wonder if it is because the image is from fedora:rawhide and something >> is too new in there and breaks the flow? >> >> https://opendev.org/openstack/magnum/commit/1de7a6af5ee2b834360e3daba34adb6b908fa035 >> >> >> On Fri, Nov 6, 2020 at 1:34 PM Ionut Biru wrote: >> >>> Hi, >>> >>> I'm using stable/victoria. It works fine with an older image. >>> >>> On Fri, Nov 6, 2020 at 1:28 PM Spyros Trigazis >>> wrote: >>> >>>> I see, this says kubectl misconfigured not missing. >>>> error: Missing or incomplete configuration info. Please point to an >>>> existing, complete config file: >>>> >>>> I guess you miss some patches: >>>> https://review.opendev.org/#/q/I15ef91bbec20a8037d47902225eabb3082579705 >>>> >>>> Try using an older image of the agent or take the patch above. >>>> >>>> Spyros >>>> >>>> On Fri, Nov 6, 2020 at 12:01 PM Ionut Biru wrote: >>>> >>>>> Hi, >>>>> >>>>> Not sure if because kubectl is not found but here are the logs, I >>>>> cannot figure out why it is not working with the new heat image. >>>>> >>>>> journalctl https://paste.xinu.at/jsA/ >>>>> heat-config master https://paste.xinu.at/pEz/ >>>>> heat-config master cluster config https://paste.xinu.at/K85ZY5/ >>>>> >>>>> [root at cluster001-7dby23lm6ods-master-0 heat-config-script]# kubectl >>>>> get pods --all-namespaces >>>>> No resources found >>>>> [root at cluster001-7dby23lm6ods-master-0 heat-config-script]# kubectl >>>>> get all --all-namespaces >>>>> NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP >>>>> PORT(S) AGE >>>>> default service/kubernetes ClusterIP 10.254.0.1 >>>>> 443/TCP 36m >>>>> >>>>> It fails to deploy and I don't have any services configured. >>>>> >>>>> On Fri, Nov 6, 2020 at 12:43 PM Spyros Trigazis >>>>> wrote: >>>>> >>>>>> Am I missing something? It is there. >>>>>> >>>>>> Spyros >>>>>> >>>>>> ubuntu at str-focal-2xlarge-01:~$ docker run -it --entrypoint >>>>>> /usr/bin/kubectl openstackmagnum/heat-container-agent:victoria-dev version >>>>>> --client --short >>>>>> Client Version: v1.18.2 >>>>>> ubuntu at str-focal-2xlarge-01:~$ docker run -it --entrypoint >>>>>> /usr/bin/kubectl openstackmagnum/heat-container-agent at sha256:0f354341b1970b7dacd9825a1c7585bae5495842416123941965574374922b51 >>>>>> version --client --short >>>>>> Client Version: v1.18.2 >>>>>> >>>>>> On Fri, Nov 6, 2020 at 11:33 AM Ionut Biru wrote: >>>>>> >>>>>>> I wanted to say, 20 hours ago instead of days. >>>>>>> >>>>>>> On Fri, Nov 6, 2020 at 12:33 PM Ionut Biru wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> 20 days ago the image was updated and now all clusters fail to >>>>>>>> deploy because it cannot find >>>>>>>> /usr/bin/kubectl, i think. >>>>>>>> >>>>>>>> /usr/bin/kubectl apply -f >>>>>>>> /srv/magnum/kubernetes/manifests/calico-deploy.yaml --namespace=kube-system >>>>>>>> >>>>>>>> Some services are installed using full path instead of simply >>>>>>>> kubectl. >>>>>>>> >>>>>>>> Should the image be fixed or reverted the changes to old revision >>>>>>>> or we should just fix the scripts? >>>>>>>> >>>>>>>> -- >>>>>>>> Ionut Biru - https://fleio.com >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Ionut Biru - https://fleio.com >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Ionut Biru - https://fleio.com >>>>> >>>> >>> >>> -- >>> Ionut Biru - https://fleio.com >>> >> >> >> -- >> Ionut Biru - https://fleio.com >> > -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry at openstack.org Fri Nov 6 12:47:11 2020 From: thierry at openstack.org (Thierry Carrez) Date: Fri, 6 Nov 2020 13:47:11 +0100 Subject: [Release-job-failures] Release of openstack/ansible-role-redhat-subscription for ref refs/tags/1.1.1 failed In-Reply-To: References: <642745d9-ca22-3830-c9d1-36f3e97a458d@openstack.org> Message-ID: The weird thing is that the PyPI error message says: "The description failed to render in the default format of reStructuredText" while we specify: long_description_content_type='text/markdown' in setup.py. It looks like PyPI is ignoring our indication in setup.py, and therefore (accurately) reporting failure to render in RST. Herve Beraud wrote: > I confirm the markdown issue was fixed 1 year ago [1] by myself and > since 3 new versions of ansible-role-redhat-subscription have been > released [2]. > > The markdown fix is embedded in the three releases: > $ git tag --contains fceb51c66e > 1.0.4 > 1.1.0 > 1.1.1 > > 2 releases was successfully uploaded to pypi: > - https://pypi.org/project/ansible-role-redhat-subscription/1.1.0/ > - https://pypi.org/project/ansible-role-redhat-subscription/1.0.4/ > > I saw a couple of changes in your README and they seem to mix markdown > and restructuredText [3], maybe it could explain this issue but these > changes are also in previous versions: > > $ git tag --contains 0949f34ffb > 1.0.3 > 1.0.4 > 1.1.0 > 1.1.1 > > Maybe pypa introduced more strict checks on their side since our last > release... > > I tried to generate a PKG-INFO locally and everything seems ok. > > Also I didn't see any new bugs that seem related to this issue on the > pypa side [4]. > > [1] > https://opendev.org/openstack/ansible-role-redhat-subscription/commit/fceb51c66eb343a7cd20891da8728c65ff703ce7 > [2] > https://opendev.org/openstack/releases/commits/branch/master/deliverables/_independent/ansible-role-redhat-subscription.yaml > [3] > https://opendev.org/openstack/ansible-role-redhat-subscription/commit/0949f34ffb10e51787e824b00f0b5ae69592cdda > [4] > https://github.com/search?q=org%3Apypa+The+description+failed+to+render+in+the+default+format+of+reStructuredText&type=issues > > > > Le jeu. 5 nov. 2020 à 14:26, Thierry Carrez > a écrit : > > Marios Andreou wrote: > > thanks for the update on that I would have missed it if you > didn't send > > this mail. > > This is actually in reaction to a release job failure email that I > received, so that we discuss the solution on the list. There was no > prior email on the topic. > > > I am a bit confused though as you mentioned 1.1.0 here do you > > mean this is something to do with the > ansible-role-redhat-subscription > > repo itself? > > The failure is linked to the content of the repository: basically, PyPI > is rejecting how the README is specified. So it will likely require a > patch to ansible-role-redhat-subscription itself, in which case we'd > push a new tag (1.1.2). > > That said, it's unclear what the problem is, as the same problem was > fixed[1] a year ago already and nothing really changed since the > (successful) 1.1.0 publication. We'll explore more and let you know if > there is anything you can help with :) > > [1] > https://opendev.org/openstack/ansible-role-redhat-subscription/commit/fceb51c66eb343a7cd20891da8728c65ff703ce7 > > -- > Thierry Carrez (ttx) > > > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > > > Le jeu. 5 nov. 2020 à 16:21, Marios Andreou > a écrit : > > > > On Thu, Nov 5, 2020 at 3:24 PM Thierry Carrez > wrote: > > Marios Andreou wrote: > > thanks for the update on that I would have missed it if you > didn't send > > this mail. > > This is actually in reaction to a release job failure email that I > received, so that we discuss the solution on the list. There was no > prior email on the topic. > > > I am a bit confused though as you mentioned 1.1.0 here do you > > mean this is something to do with the > ansible-role-redhat-subscription > > repo itself? > > The failure is linked to the content of the repository: > basically, PyPI > is rejecting how the README is specified. So it will likely > require a > patch to ansible-role-redhat-subscription itself, in which case > we'd > push a new tag (1.1.2). > > That said, it's unclear what the problem is, as the same problem > was > fixed[1] a year ago already and nothing really changed since the > (successful) 1.1.0 publication. We'll explore more and let you > know if > there is anything you can help with :) > > > ack! Thank you much clearer for me now. If there is an update > required then no problem we can address that and update with a newer tag > > > [1] > https://opendev.org/openstack/ansible-role-redhat-subscription/commit/fceb51c66eb343a7cd20891da8728c65ff703ce7 > > -- > Thierry Carrez (ttx) > > > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > -- Thierry Carrez (ttx) From skaplons at redhat.com Fri Nov 6 13:50:41 2020 From: skaplons at redhat.com (Slawek Kaplonski) Date: Fri, 06 Nov 2020 14:50:41 +0100 Subject: [neutron][stable]Proposing Rodolfo Alonso Hernandez as a stable branches core reviewer In-Reply-To: <1766330.tdWV9SEqCh@p1> References: <1766330.tdWV9SEqCh@p1> Message-ID: <4792298.JM3M1uNXaj@p1> Hi, There is a week since I sent this nomination and there was no any negative feedback. So I asked today and Thierry added Rodolfo to the neutron-stable-maint group. Welcome in the Neutron stable core team Rodolfo :) Dnia czwartek, 29 października 2020 12:33:04 CET Slawek Kaplonski pisze: > Hi, > > I would like to propose Rodolfo Alonso Hernandez (ralonsoh) to be new member > of the Neutron stable core team. > Rodolfo works in Neutron since very long time. He is core reviewer in master > branch already. > During last few cycles he also proved his ability to help with stable > branches. He is proposing many backports from master to our stable branches > as well as doing reviews of other backports. > He has knowledge about stable branches policies. > I think that he will be great addition to our (not too big) stable core > team. > > I will open this nomination open for a week to get feedback about it. > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat -- Slawek Kaplonski Principal Software Engineer Red Hat From hberaud at redhat.com Fri Nov 6 14:50:27 2020 From: hberaud at redhat.com (Herve Beraud) Date: Fri, 6 Nov 2020 15:50:27 +0100 Subject: [Release-job-failures] Release of openstack/ansible-role-redhat-subscription for ref refs/tags/1.1.1 failed In-Reply-To: References: <642745d9-ca22-3830-c9d1-36f3e97a458d@openstack.org> Message-ID: I reported a related bug on pypa: https://github.com/pypa/warehouse/issues/8791 Le ven. 6 nov. 2020 à 13:49, Thierry Carrez a écrit : > The weird thing is that the PyPI error message says: > > "The description failed to render in the default format of > reStructuredText" > > while we specify: > > long_description_content_type='text/markdown' > > in setup.py. It looks like PyPI is ignoring our indication in setup.py, > and therefore (accurately) reporting failure to render in RST. > > Herve Beraud wrote: > > I confirm the markdown issue was fixed 1 year ago [1] by myself and > > since 3 new versions of ansible-role-redhat-subscription have been > > released [2]. > > > > The markdown fix is embedded in the three releases: > > $ git tag --contains fceb51c66e > > 1.0.4 > > 1.1.0 > > 1.1.1 > > > > 2 releases was successfully uploaded to pypi: > > - https://pypi.org/project/ansible-role-redhat-subscription/1.1.0/ > > - https://pypi.org/project/ansible-role-redhat-subscription/1.0.4/ > > > > I saw a couple of changes in your README and they seem to mix markdown > > and restructuredText [3], maybe it could explain this issue but these > > changes are also in previous versions: > > > > $ git tag --contains 0949f34ffb > > 1.0.3 > > 1.0.4 > > 1.1.0 > > 1.1.1 > > > > Maybe pypa introduced more strict checks on their side since our last > > release... > > > > I tried to generate a PKG-INFO locally and everything seems ok. > > > > Also I didn't see any new bugs that seem related to this issue on the > > pypa side [4]. > > > > [1] > > > https://opendev.org/openstack/ansible-role-redhat-subscription/commit/fceb51c66eb343a7cd20891da8728c65ff703ce7 > > [2] > > > https://opendev.org/openstack/releases/commits/branch/master/deliverables/_independent/ansible-role-redhat-subscription.yaml > > [3] > > > https://opendev.org/openstack/ansible-role-redhat-subscription/commit/0949f34ffb10e51787e824b00f0b5ae69592cdda > > [4] > > > https://github.com/search?q=org%3Apypa+The+description+failed+to+render+in+the+default+format+of+reStructuredText&type=issues > > > > > > > > Le jeu. 5 nov. 2020 à 14:26, Thierry Carrez > > a écrit : > > > > Marios Andreou wrote: > > > thanks for the update on that I would have missed it if you > > didn't send > > > this mail. > > > > This is actually in reaction to a release job failure email that I > > received, so that we discuss the solution on the list. There was no > > prior email on the topic. > > > > > I am a bit confused though as you mentioned 1.1.0 here do you > > > mean this is something to do with the > > ansible-role-redhat-subscription > > > repo itself? > > > > The failure is linked to the content of the repository: basically, > PyPI > > is rejecting how the README is specified. So it will likely require a > > patch to ansible-role-redhat-subscription itself, in which case we'd > > push a new tag (1.1.2). > > > > That said, it's unclear what the problem is, as the same problem was > > fixed[1] a year ago already and nothing really changed since the > > (successful) 1.1.0 publication. We'll explore more and let you know > if > > there is anything you can help with :) > > > > [1] > > > https://opendev.org/openstack/ansible-role-redhat-subscription/commit/fceb51c66eb343a7cd20891da8728c65ff703ce7 > > > > -- > > Thierry Carrez (ttx) > > > > > > > > -- > > Hervé Beraud > > Senior Software Engineer at Red Hat > > irc: hberaud > > https://github.com/4383/ > > https://twitter.com/4383hberaud > > -----BEGIN PGP SIGNATURE----- > > > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > > v6rDpkeNksZ9fFSyoY2o > > =ECSj > > -----END PGP SIGNATURE----- > > > > > > Le jeu. 5 nov. 2020 à 16:21, Marios Andreou > > a écrit : > > > > > > > > On Thu, Nov 5, 2020 at 3:24 PM Thierry Carrez > > wrote: > > > > Marios Andreou wrote: > > > thanks for the update on that I would have missed it if you > > didn't send > > > this mail. > > > > This is actually in reaction to a release job failure email that > I > > received, so that we discuss the solution on the list. There was > no > > prior email on the topic. > > > > > I am a bit confused though as you mentioned 1.1.0 here do you > > > mean this is something to do with the > > ansible-role-redhat-subscription > > > repo itself? > > > > The failure is linked to the content of the repository: > > basically, PyPI > > is rejecting how the README is specified. So it will likely > > require a > > patch to ansible-role-redhat-subscription itself, in which case > > we'd > > push a new tag (1.1.2). > > > > That said, it's unclear what the problem is, as the same problem > > was > > fixed[1] a year ago already and nothing really changed since the > > (successful) 1.1.0 publication. We'll explore more and let you > > know if > > there is anything you can help with :) > > > > > > ack! Thank you much clearer for me now. If there is an update > > required then no problem we can address that and update with a newer > tag > > > > > > [1] > > > https://opendev.org/openstack/ansible-role-redhat-subscription/commit/fceb51c66eb343a7cd20891da8728c65ff703ce7 > > > > -- > > Thierry Carrez (ttx) > > > > > > > > -- > > Hervé Beraud > > Senior Software Engineer at Red Hat > > irc: hberaud > > https://github.com/4383/ > > https://twitter.com/4383hberaud > > -----BEGIN PGP SIGNATURE----- > > > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > > v6rDpkeNksZ9fFSyoY2o > > =ECSj > > -----END PGP SIGNATURE----- > > > > > -- > Thierry Carrez (ttx) > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Arkady.Kanevsky at dell.com Fri Nov 6 15:15:57 2020 From: Arkady.Kanevsky at dell.com (Kanevsky, Arkady) Date: Fri, 6 Nov 2020 15:15:57 +0000 Subject: [openstack][InteropWG] : Interop weekly Friday call In-Reply-To: <1676177545.2373771.1604645255017@mail.yahoo.com> References: <1295138775.3349683.1603717569398.ref@mail.yahoo.com> <1295138775.3349683.1603717569398@mail.yahoo.com> <1791751856.3420249.1603726712148@mail.yahoo.com> <352076537.476027.1604015407570@mail.yahoo.com> <1829403956.43078.1604102260422@mail.yahoo.com> <1757fc3ee30.eea7e45388786.4328160222881040161@ghanshyammann.com> <1676177545.2373771.1604645255017@mail.yahoo.com> Message-ID: Team, I will have to miss today’s call From: prakash RAMCHANDRAN Sent: Friday, November 6, 2020 12:48 AM To: Ghanshyam Mann Cc: openstack-discuss at lists.openstack.org; Voelker, Mark (VMware); Kanevsky, Arkady; Goutham Pacha Ravi Subject: Re: [openstack][InteropWG] : Interop weekly Friday call [EXTERNAL EMAIL] Hi all, Thanks Ghanshyam we may no impact based on zuul v3 for testing using tempest. If we submit a new guideline for 2020.10.json where will I see the patch under https://devops.org/osf/interior or patch? osf/interop Let's ho over the call tomorrow 10 AM PST. Please join and add your topics to https://etherpad.opendev.org/p/interop The meet pad link for call is on eitherpad. Thanks Prakash Sent from Yahoo Mail on Android On Sat, Oct 31, 2020 at 10:45 AM, Ghanshyam Mann > wrote: ---- On Fri, 30 Oct 2020 18:57:40 -0500 prakash RAMCHANDRAN > wrote ---- > Hi all, > We have few major Tasks to elevate Interop WG to enable OpenStack + Open Infrastructure Branding and Logo Programs: > 1. https://opendev.org/osf/interop/src/branch/master/2020.06.json (To patch and update to 2020.10.json)All core module owners of Integrated OpenStack please respond before next Friday Nov 6 -Interop WG call on meetpad > Interop Working Group - Weekly Friday 10-11 AM or UTC 17-18 (Next on Nov 6 & 13th)Lnink: https://meetpad.opendev.org/Interop-WG-weekly-meeting > Checklist for PTLs (core - keystone, glance, nova, neutron, cinder & swift) and add-ons (heat & designate) > 1. Did the Victoria switch for Jenkins to Zuul V3 and move to new Ubuntu Focal impact your DevStack and Tempesting module feature testing in any way for Interop? It is moved from zuulv2 native jobs to zuulv3 native and Ubuntu Bionic to Ubuntu Focal which basically are only testing framework side updates not on any user facing interface updates so it will not impact any interop way. -gmann > 2. Pease check https://opendev.org/osf/interop/src/branch/master/2020.06.json#L72We will drop stein and add wallaby, hence train release notes will be the base line for feature retention and compliance baseline testing > Please verify what are the changes you may need for Victoria cycle for Logo program for your modules list all"required": [] > "advisory": [], > "deprecated": [], > "removed": [] > > 3. Reply by email the changes expected for us the review based on your Victoria release notes or add notes to https://releases.openstack.org/victoria/?_ga=2.174650977.277942436.1604012691-802386709.1603466376 > > > 4. Discussions on Manila - Need Volunteer 5. Discussions on Ironic - Need Volunteers 6. Discussion on future Kata GoLang - Kata (with tempest vs k8s test tools or https://onsi.github.io/ginkgo/ + Airship, Starlingx, Zuul on infralab ?) - Need Volunteers > > ThanksPrakashFor Interop WG > ================================================================================================================== > > > Hi all, > We have two sessions one at 13 UTC ( 6 AM PDT) and 16 UTC (9 AM PDT) > Based on our interactions and collaborations - Manila team met and I could not attend their call but here is the link to their efforts: > https://etherpad.opendev.org/p/wallaby-ptg-manila-interop > We have 4 items to cover and seeking Volunteers for possible Manila & kubernetes Kata + RUNC based Container compliance (GoLang Must) > Also we are planning to introduce GoLang based Refstak/Tempest if there are volunteers ready to work with QA team (Gmann). > Thus we can finish in 1 session at 13 UTC and plan to cancel the second session at 16 UTC.====================================================================================================Your comments > > > > > ======================================================================================================See you for Interop and add any comments above > ThanksPrakashFor Interop WG > On Monday, October 26, 2020, 08:38:32 AM PDT, prakash RAMCHANDRAN > wrote: > > Hi all > My apology on the delayed start and here is the items we went over on first session. > Refer : https://etherpad.opendev.org/p/interop-wallaby-ptg (Monday 10/26 recorded the meeting for everyone to see, its cloud recording and will know from PTG hosts where they have that?) > Summary:1. Plan to Complete Victoria guidelines specs for interop in 2-6 weeks depending on adding new [OpenStack Powered File System Branding as Add-on Program] > - last Ussuri guidelines are at https://opendev.org/osf/interop/src/branch/master/2020.06.json > > > > New one will be 2020.10.json to be added > - For existing integrated modules [ Core OpenStack services including identity, compute, networking, block storage, and object storage ] - for two existing add-ons [Orchestration (heat) , DNS (designate) "Not a core capability, add-on program is available" - This is for Manila Filesystem add-on OpenDev Etherpad "Not a core capability, add-on program to be made available" > OpenDev Etherpad > > > > > > > > > We have one more opportunity on 10/30 slot at the end of PTG if BMaaS (Ironic) if Julia has any proposals, besides (Open Infra Kata + Docker) Container has additional proposal community is working on. Look forward to seeing you all on October 30 as what the Road-map will look like for 2020 and 2021 going forward. > ThanksPrakash > > On Monday, October 26, 2020, 06:09:00 AM PDT, Goutham Pacha Ravi > wrote: > > Hi Prakash, > > We're here: https://zoom.us/j/92649902134?pwd=a01aMXl6ZlNEZDlsMjJMTGNMVUp1UT09 > > On Mon, Oct 26, 2020 at 6:06 AM prakash RAMCHANDRAN > wrote: > https://meetpad.opendev.org/Interop-WG-weekly-meeting > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralonsoh at redhat.com Fri Nov 6 15:37:31 2020 From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez) Date: Fri, 6 Nov 2020 16:37:31 +0100 Subject: [neutron][stable]Proposing Rodolfo Alonso Hernandez as a stable branches core reviewer In-Reply-To: <4792298.JM3M1uNXaj@p1> References: <1766330.tdWV9SEqCh@p1> <4792298.JM3M1uNXaj@p1> Message-ID: Thank you all. It will be a pleasure to have the ability to break stables branches too! (I'm sorry in advance, Bernard) Regards. On Fri, Nov 6, 2020 at 2:50 PM Slawek Kaplonski wrote: > Hi, > > There is a week since I sent this nomination and there was no any negative > feedback. > So I asked today and Thierry added Rodolfo to the neutron-stable-maint > group. > Welcome in the Neutron stable core team Rodolfo :) > > Dnia czwartek, 29 października 2020 12:33:04 CET Slawek Kaplonski pisze: > > Hi, > > > > I would like to propose Rodolfo Alonso Hernandez (ralonsoh) to be new > member > > of the Neutron stable core team. > > Rodolfo works in Neutron since very long time. He is core reviewer in > master > > branch already. > > During last few cycles he also proved his ability to help with stable > > branches. He is proposing many backports from master to our stable > branches > > as well as doing reviews of other backports. > > He has knowledge about stable branches policies. > > I think that he will be great addition to our (not too big) stable core > > team. > > > > I will open this nomination open for a week to get feedback about it. > > > > -- > > Slawek Kaplonski > > Principal Software Engineer > > Red Hat > > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliver.wenz at dhbw-mannheim.de Fri Nov 6 15:43:51 2020 From: oliver.wenz at dhbw-mannheim.de (Oliver Wenz) Date: Fri, 6 Nov 2020 16:43:51 +0100 Subject: [openstack-ansible][nova] os-nova-install.yml playbook fails after being unable to restart libvirtd.service on compute nodes In-Reply-To: References: Message-ID: <39c3de9f-7017-1e57-1153-5fbf8c6c99d5@dhbw-mannheim.de> To enable live migration on an ussuri (deployed using OpenStack Ansible) I set up a shared filesystem (ocfs2) on the compute hosts. Then I added the following to /etc/openstack_deploy/user_variables.yml and reran the os-nova-install.yml playbook: ``` nova_nova_conf_overrides: libvirt: iscsi_use_multipath: true nova_system_user_uid: 999 nova_system_group_gid: 999 nova_novncproxy_vncserver_listen: 0.0.0.0 # Disable libvirtd's TLS listener nova_libvirtd_listen_tls: 0 # Enable libvirtd's plaintext TCP listener nova_libvirtd_listen_tcp: 1 nova_libvirtd_auth_tcp: none ``` The playbook failed with the following message: ``` RUNNING HANDLER [os_nova : Restart libvirt-bin] *************************************************************************** fatal: [compute1]: FAILED! => {"changed": false, "msg": "Unable to restart service libvirtd: Job for libvirtd.service failed because the control process exited with error code.\nSee \"systemctl status libvirtd.service\" and \"journalctl -xe\" for details.\n"} ``` (similar for the other compute nodes) Running 'systemctl status libvirtd.service' revealed that the service failed to start (code=exited, status=6). Here's the 'journalctl -xe' output: ``` Nov 06 12:42:20 bc1bl12 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=libvirtd comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' Nov 06 12:42:20 bc1bl12 systemd[1]: libvirtd.service: Service hold-off time over, scheduling restart. Nov 06 12:42:20 bc1bl12 systemd[1]: libvirtd.service: Scheduled restart job, restart counter is at 5. -- Subject: Automatic restarting of a unit has been scheduled -- Defined-By: systemd -- Support: http://www.ubuntu.com/support -- -- Automatic restarting of the unit libvirtd.service has been scheduled, as the result for -- the configured Restart= setting for the unit. Nov 06 12:42:20 bc1bl12 systemd[1]: Stopped Virtualization daemon. -- Subject: Unit libvirtd.service has finished shutting down -- Defined-By: systemd -- Support: http://www.ubuntu.com/support -- -- Unit libvirtd.service has finished shutting down. Nov 06 12:42:20 bc1bl12 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=libvirtd comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Nov 06 12:42:20 bc1bl12 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=libvirtd comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Nov 06 12:42:20 bc1bl12 systemd[1]: libvirtd.service: Start request repeated too quickly. Nov 06 12:42:20 bc1bl12 systemd[1]: libvirtd.service: Failed with result 'exit-code'. Nov 06 12:42:20 bc1bl12 systemd[1]: Failed to start Virtualization daemon. -- Subject: Unit libvirtd.service has failed -- Defined-By: systemd -- Support: http://www.ubuntu.com/support -- -- Unit libvirtd.service has failed. -- -- The result is RESULT. Nov 06 12:42:20 bc1bl12 systemd[1]: libvirtd-admin.socket: Failed with result 'service-start-limit-hit'. Nov 06 12:42:20 bc1bl12 systemd[1]: libvirtd.socket: Failed with result 'service-start-limit-hit'. Nov 06 12:42:20 bc1bl12 systemd[1]: libvirtd-ro.socket: Failed with result 'service-start-limit-hit'. Nov 06 12:42:20 bc1bl12 systemd[1]: Closed Libvirt local read-only socket. -- Subject: Unit libvirtd-ro.socket has finished shutting down -- Defined-By: systemd -- Support: http://www.ubuntu.com/support -- -- Unit libvirtd-ro.socket has finished shutting down. ``` The /etc/libvirt/libvirtd.conf file written by OpenStack Ansible looks like this: ``` listen_tls = 0 listen_tcp = 1 unix_sock_group = "libvirt" unix_sock_ro_perms = "0777" unix_sock_rw_perms = "0770" auth_unix_ro = "none" auth_unix_rw = "none" auth_tcp = "none" ``` I've encountered mentions of /etc/default/libvirt-bin in documentation for older OpenStack versions and I'm unsure if something went wrong with the playbooks, because the file doesn't exist on my compute nodes. Any ideas that might help are highly appreciated! Kind regards, Oliver From skaplons at redhat.com Fri Nov 6 16:45:36 2020 From: skaplons at redhat.com (Slawek Kaplonski) Date: Fri, 06 Nov 2020 17:45:36 +0100 Subject: [neutron]Drivers meeting 06.11.2020 - cancelled In-Reply-To: References: <3846730.JagzSZ0HJ7@p1> <4adbaaa5-f795-0537-f26e-5547bad5d978@gmail.com> Message-ID: <3671273.rczrtDRm1T@p1> Hi, If You have something what You want to discuss during drivers meeting, please go to https://wiki.openstack.org/wiki/Meetings/NeutronDrivers page before the meeting and add Your topic to the "On Demand" agenda. And please do that on Thursday, before I will start preparing meeting which I usually do around Thursday evening CEST time. If I don't see anything in the agenda I'm cancelling the meeting but if there would be something added there, then meeting would be run normally. Dnia piątek, 6 listopada 2020 10:56:35 CET Rafael Weingärtner pisze: > Great, thanks! > > Em sex, 6 de nov de 2020 00:16, Brian Haley escreveu: > > On 11/5/20 4:05 PM, Rafael Weingärtner wrote: > > > I had a topic for this meeting. I wanted to ask about the spec > > > https://review.opendev.org/#/c/739549/. > > > Do we need other meetings to discuss it? Or, is the spec and the > > > discussions we had there enough? We wanted to see it going out in > > > Wallaby release. > > > > From https://bugs.launchpad.net/neutron/+bug/1885921/comments/4 this > > > > RFE was approved. I see you just had to re-target it to Wallaby, which > > is fine, I think we can continue any further discussions in the reviews. > > > > -Brian > > > > > On Thu, Nov 5, 2020 at 5:39 PM Slawek Kaplonski > > > > > > wrote: > > > Hi, > > > > > > We don't have any new RFEs to discuss so lets cancel tomorrow's > > > > drivers > > > > > meeting. > > > There is one fresh RFE [1] but we discussed that durig the PTG so > > > now lets > > > wait for proposed spec with more details and we will get back to > > > discussion > > > about approval of it in the drivers meeting in next weeks. > > > Have a great weekend. > > > > > > [1] https://bugs.launchpad.net/neutron/+bug/1900934 > > > > > > -- > > > Slawek Kaplonski > > > Principal Software Engineer > > > Red Hat > > > > > > -- > > > Rafael Weingärtner -- Slawek Kaplonski Principal Software Engineer Red Hat From fungi at yuggoth.org Fri Nov 6 17:35:21 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 6 Nov 2020 17:35:21 +0000 Subject: [Release-job-failures] Release of openstack/ansible-role-redhat-subscription for ref refs/tags/1.1.1 failed In-Reply-To: References: <642745d9-ca22-3830-c9d1-36f3e97a458d@openstack.org> Message-ID: <20201106173521.3xmgzwoqs2s4hkep@yuggoth.org> On 2020-11-06 13:47:11 +0100 (+0100), Thierry Carrez wrote: > The weird thing is that the PyPI error message says: > > "The description failed to render in the default format of reStructuredText" > > while we specify: > > long_description_content_type='text/markdown' > > in setup.py. It looks like PyPI is ignoring our indication in setup.py, and > therefore (accurately) reporting failure to render in RST. [...] After nearly hitting bedrock, I think I've dug down far enough to figure this one out: Between the working and failing uploads, we switched our CI system to install the wheel module from distro packaging rather than from PyPI by default. Since the recent build was performed on an Ubuntu 18.04 LTS instance, it used the available python3-wheel 0.30.0-0.2 available there. As wheel did not introduce support for Python packaging metadata version 2.1 until its 0.31.0 release, the failing upload declared "Metadata-Version: 2.0" in the METADATA file. This seems to cause the "Description-Content-Type: text/markdown" line (first introduced in the metadata 2.1 specification) to be ignored and fall back to assuming the long description is in the reStructuredText default. I propose we switch release jobs to run on an ubuntu-focal nodeset, as most official OpenStack jobs did already during the Victoria cycle. This will result in using python3-wheel 0.34.2-1 which is plenty new enough to support the necessary metadata version. If for some reason running release jobs for older stable branches on a newer distro causes issues, we can try to make use of Zuul's new branch-guessing mechanism for Git tags to create job variants running stable point releases for older branches on the older nodeset. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From fungi at yuggoth.org Fri Nov 6 17:50:52 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 6 Nov 2020 17:50:52 +0000 Subject: [Release-job-failures] Release of openstack/ansible-role-redhat-subscription for ref refs/tags/1.1.1 failed In-Reply-To: <20201106173521.3xmgzwoqs2s4hkep@yuggoth.org> References: <642745d9-ca22-3830-c9d1-36f3e97a458d@openstack.org> <20201106173521.3xmgzwoqs2s4hkep@yuggoth.org> Message-ID: <20201106175052.7v3iwde5aw43xuy4@yuggoth.org> On 2020-11-06 17:35:21 +0000 (+0000), Jeremy Stanley wrote: [...] > I propose we switch release jobs to run on an ubuntu-focal nodeset, > as most official OpenStack jobs did already during the Victoria > cycle. [...] Now up for review: https://review.opendev.org/761776 -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From steve.vezina at gmail.com Fri Nov 6 01:38:37 2020 From: steve.vezina at gmail.com (=?UTF-8?Q?Steve_V=C3=A9zina?=) Date: Thu, 5 Nov 2020 20:38:37 -0500 Subject: [neutron] Multi-AZ without L2 spanning between datacenter for external network Message-ID: Hi everyone, I am wondering if anyone got a multi-az deployment using OVS that work with seperate network fabrics which mean no L2 spanning between the AZs for external network? Thanks! Steve. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fsbiz at yahoo.com Fri Nov 6 23:45:23 2020 From: fsbiz at yahoo.com (fsbiz at yahoo.com) Date: Fri, 6 Nov 2020 23:45:23 +0000 (UTC) Subject: [swift]: issues with multi region (swift as backend for glance) References: <46812675.2700917.1604706323822.ref@mail.yahoo.com> Message-ID: <46812675.2700917.1604706323822@mail.yahoo.com> Hi folks, We're on queens release.  We have just setup a 2nd region.  So, now we have two regions regionOne and regionTwo We had a storage cluster in regionOne. Everything works good.We also added another storage cluster in regionTwo and have created swift endpoints for this.Using swift API, everything works fine.  The container is properly created in regionOne or regionTwo asdesired. We are also using swift as the glance backend.  We are seeing an issue with this for regionTwo.When I create an image in regionTwo, it seems like the glance storage backend is not properly recognizingthe endpoint and wants to store the image in regionOne. This looks like a definite bug.I can work around it by overriding the endpoint using swift_store_endpoint but if there is a known bugabout this issue I would rather patch it than resort to overriding the URL endpoint returned from "auth". Is this a known bug ?  Again, we are on the latest Queens release. thanks,Fred. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gabriel.gamero at pucp.edu.pe Sun Nov 8 03:06:50 2020 From: gabriel.gamero at pucp.edu.pe (Gabriel Omar Gamero Montenegro) Date: Sat, 7 Nov 2020 22:06:50 -0500 Subject: [neutron] Use the same network interface with multiple ML2 mechanism drivers Message-ID: Dear all, I know that ML2 Neutron core plugin is designed to support multiple mechanism and type drivers simultaneously. But I'd like to know: is it possible to use the same network interface configured with different ML2 mechanism drivers? I'm planning to use openvswitch and linuxbridge as mechanism drivers along with VLAN as type driver. Could it be possible to have the following configuration for that purpose?: ml2_conf.ini: [ml2] mechanism_drivers = openvswitch,linuxbridge [ml2_type_vlan] network_vlan_ranges = physnet1:40:60,physnet2:60:80 eth3 is a port of the provider bridge: ovs-vsctl add-port br-provider eth3 openvswitch_agent.ini: [ovs] bridge_mappings = physnet1:br-provider linuxbridge_agent.ini: [linux_bridge] physical_interface_mappings = physnet2:eth3 If it's mandatory to use different network interfaces any guide or sample reference about implementing multiple mechanism drivers would be highly appreciated. Thanks in advance, Gabriel Gamero From satish.txt at gmail.com Sun Nov 8 14:31:23 2020 From: satish.txt at gmail.com (Satish Patel) Date: Sun, 8 Nov 2020 09:31:23 -0500 Subject: openvswitch+dpdk 100% cpu usage of ovs-vswitchd Message-ID: Folks, Recently i have added come compute nodes in cloud supporting openvswitch-dpdk for performance. I am seeing all my PMD cpu cores are 100% cpu usage on linux top command. It is normal behavior from first looks. It's very scary to see 400% cpu usage on top. Can someone confirm before I assume it's normal and what we can do to reduce it if it's too high? From florian at datalounges.com Sun Nov 8 15:00:23 2020 From: florian at datalounges.com (Florian Rommel) Date: Sun, 8 Nov 2020 17:00:23 +0200 Subject: [octavia] Timeouts during building of lb? But then successful Message-ID: <6266636F-EB91-4CAC-B5CA-228710483B67@datalounges.com> Hi, so we have a fully functioning setup of octavia on ussuri and it works nicely, when it competes. So here is what happens: From octavia api to octavia worker takes 20 seconds for the job to be initiated. The loadbalancer gets built quickly and then we get a mysql went away error, the listener gets built and then a member , that works too, then the mysql error comes up with query took too long to execute. Now this is where it gets weird. This is all within the first 2 - 3 minutes. At this point it hangs and takes 10 minutes (600 seconds) for the next step to complete and then another 10 minutes and another 10 until it’s completed. It seems there is a timeout somewhere but even with debug on we do not see what is going on. Does anyone have a mysql 8 running and octavia executing fine? And could send me their redacted octavia or mysql conf files? We didn’t touch them but it seems that there is something off.. especially since it then completes and works extremely nicely. I would highly appreciate it , even off list. Best regards, //f From laurentfdumont at gmail.com Sun Nov 8 15:49:53 2020 From: laurentfdumont at gmail.com (Laurent Dumont) Date: Sun, 8 Nov 2020 10:49:53 -0500 Subject: openvswitch+dpdk 100% cpu usage of ovs-vswitchd In-Reply-To: References: Message-ID: As far as I know, DPDK enabled cores will show 100% usage at all times. On Sun, Nov 8, 2020 at 9:39 AM Satish Patel wrote: > Folks, > > Recently i have added come compute nodes in cloud supporting > openvswitch-dpdk for performance. I am seeing all my PMD cpu cores are > 100% cpu usage on linux top command. It is normal behavior from first > looks. It's very scary to see 400% cpu usage on top. Can someone > confirm before I assume it's normal and what we can do to reduce it if > it's too high? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Sun Nov 8 16:13:44 2020 From: satish.txt at gmail.com (Satish Patel) Date: Sun, 8 Nov 2020 11:13:44 -0500 Subject: openvswitch+dpdk 100% cpu usage of ovs-vswitchd In-Reply-To: References: Message-ID: Thanks. Just curious then why people directly go for SR-IOV implementation where they get better performance + they can use the same CPU more also. What are the measure advantages or features attracting the community to go with DPDK over SR-IOV? On Sun, Nov 8, 2020 at 10:50 AM Laurent Dumont wrote: > > As far as I know, DPDK enabled cores will show 100% usage at all times. > > On Sun, Nov 8, 2020 at 9:39 AM Satish Patel wrote: >> >> Folks, >> >> Recently i have added come compute nodes in cloud supporting >> openvswitch-dpdk for performance. I am seeing all my PMD cpu cores are >> 100% cpu usage on linux top command. It is normal behavior from first >> looks. It's very scary to see 400% cpu usage on top. Can someone >> confirm before I assume it's normal and what we can do to reduce it if >> it's too high? >> From laurentfdumont at gmail.com Sun Nov 8 17:04:10 2020 From: laurentfdumont at gmail.com (Laurent Dumont) Date: Sun, 8 Nov 2020 12:04:10 -0500 Subject: openvswitch+dpdk 100% cpu usage of ovs-vswitchd In-Reply-To: References: Message-ID: I have limited hands-on experience with both but they don't serve the same purpose/have the same implementation. You use SRIOV to allow Tenants to access the NIC cards directly and bypass any inherent linux-vr/OVS performance limitations. This is key for NFV workloads which are expecting large amount of PPS + low latency (because they are often just virtualized bare-metal products with one real cloud-readiness/architecture ;) ) - This means that a Tenant with an SRIOV port can use DPDK + access the NIC through the VF which means (in theory) a better performance than OVS+DPDK. You use ovs-dpdk to increase the performance of OVS based flows (so provider networks + vxlan based internal-tenant networks). On Sun, Nov 8, 2020 at 11:13 AM Satish Patel wrote: > Thanks. Just curious then why people directly go for SR-IOV > implementation where they get better performance + they can use the > same CPU more also. What are the measure advantages or features > attracting the community to go with DPDK over SR-IOV? > > On Sun, Nov 8, 2020 at 10:50 AM Laurent Dumont > wrote: > > > > As far as I know, DPDK enabled cores will show 100% usage at all times. > > > > On Sun, Nov 8, 2020 at 9:39 AM Satish Patel > wrote: > >> > >> Folks, > >> > >> Recently i have added come compute nodes in cloud supporting > >> openvswitch-dpdk for performance. I am seeing all my PMD cpu cores are > >> 100% cpu usage on linux top command. It is normal behavior from first > >> looks. It's very scary to see 400% cpu usage on top. Can someone > >> confirm before I assume it's normal and what we can do to reduce it if > >> it's too high? > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonyliu0592 at hotmail.com Sun Nov 8 20:22:47 2020 From: tonyliu0592 at hotmail.com (Tony Liu) Date: Sun, 8 Nov 2020 20:22:47 +0000 Subject: openvswitch+dpdk 100% cpu usage of ovs-vswitchd In-Reply-To: References: Message-ID: SRIOV gives you the maximum performance, without any SW features (security group, L3 routing, etc.), because it bypasses SW. DPDK gives you less performance, with all SW features. Depend on the use case, max perf and SW features, you will need to make a decision. Tony > -----Original Message----- > From: Laurent Dumont > Sent: Sunday, November 8, 2020 9:04 AM > To: Satish Patel > Cc: OpenStack Discuss > Subject: Re: openvswitch+dpdk 100% cpu usage of ovs-vswitchd > > I have limited hands-on experience with both but they don't serve the > same purpose/have the same implementation. You use SRIOV to allow > Tenants to access the NIC cards directly and bypass any inherent linux- > vr/OVS performance limitations. This is key for NFV workloads which are > expecting large amount of PPS + low latency (because they are often just > virtualized bare-metal products with one real cloud- > readiness/architecture ;) ) - This means that a Tenant with an SRIOV > port can use DPDK + access the NIC through the VF which means (in theory) > a better performance than OVS+DPDK. > > You use ovs-dpdk to increase the performance of OVS based flows (so > provider networks + vxlan based internal-tenant networks). > > On Sun, Nov 8, 2020 at 11:13 AM Satish Patel > wrote: > > > Thanks. Just curious then why people directly go for SR-IOV > implementation where they get better performance + they can use the > same CPU more also. What are the measure advantages or features > attracting the community to go with DPDK over SR-IOV? > > On Sun, Nov 8, 2020 at 10:50 AM Laurent Dumont > > wrote: > > > > As far as I know, DPDK enabled cores will show 100% usage at all > times. > > > > On Sun, Nov 8, 2020 at 9:39 AM Satish Patel > wrote: > >> > >> Folks, > >> > >> Recently i have added come compute nodes in cloud supporting > >> openvswitch-dpdk for performance. I am seeing all my PMD cpu > cores are > >> 100% cpu usage on linux top command. It is normal behavior from > first > >> looks. It's very scary to see 400% cpu usage on top. Can someone > >> confirm before I assume it's normal and what we can do to reduce > it if > >> it's too high? > >> > From satish.txt at gmail.com Mon Nov 9 02:50:37 2020 From: satish.txt at gmail.com (Satish Patel) Date: Sun, 8 Nov 2020 21:50:37 -0500 Subject: openvswitch+dpdk 100% cpu usage of ovs-vswitchd In-Reply-To: References: Message-ID: Thank you tony, We are running openstack cloud with SR-IOV and we are happy with performance but one big issue, it doesn't support bonding on compute nodes, we can do bonding inside VM but that is over complicated to do that level of deployment, without bonding it's always risky if tor switch dies. that is why i started looking into DPDK but look like i hit the wall again because my compute node has only 2 NIC we i can't do bonding while i am connected over same nic. Anyway i will stick with SR-IOV in that case to get more performance and less complexity. On Sun, Nov 8, 2020 at 3:22 PM Tony Liu wrote: > > SRIOV gives you the maximum performance, without any SW features > (security group, L3 routing, etc.), because it bypasses SW. > DPDK gives you less performance, with all SW features. > > Depend on the use case, max perf and SW features, you will need > to make a decision. > > > Tony > > -----Original Message----- > > From: Laurent Dumont > > Sent: Sunday, November 8, 2020 9:04 AM > > To: Satish Patel > > Cc: OpenStack Discuss > > Subject: Re: openvswitch+dpdk 100% cpu usage of ovs-vswitchd > > > > I have limited hands-on experience with both but they don't serve the > > same purpose/have the same implementation. You use SRIOV to allow > > Tenants to access the NIC cards directly and bypass any inherent linux- > > vr/OVS performance limitations. This is key for NFV workloads which are > > expecting large amount of PPS + low latency (because they are often just > > virtualized bare-metal products with one real cloud- > > readiness/architecture ;) ) - This means that a Tenant with an SRIOV > > port can use DPDK + access the NIC through the VF which means (in theory) > > a better performance than OVS+DPDK. > > > > You use ovs-dpdk to increase the performance of OVS based flows (so > > provider networks + vxlan based internal-tenant networks). > > > > On Sun, Nov 8, 2020 at 11:13 AM Satish Patel > > wrote: > > > > > > Thanks. Just curious then why people directly go for SR-IOV > > implementation where they get better performance + they can use the > > same CPU more also. What are the measure advantages or features > > attracting the community to go with DPDK over SR-IOV? > > > > On Sun, Nov 8, 2020 at 10:50 AM Laurent Dumont > > > wrote: > > > > > > As far as I know, DPDK enabled cores will show 100% usage at all > > times. > > > > > > On Sun, Nov 8, 2020 at 9:39 AM Satish Patel > > wrote: > > >> > > >> Folks, > > >> > > >> Recently i have added come compute nodes in cloud supporting > > >> openvswitch-dpdk for performance. I am seeing all my PMD cpu > > cores are > > >> 100% cpu usage on linux top command. It is normal behavior from > > first > > >> looks. It's very scary to see 400% cpu usage on top. Can someone > > >> confirm before I assume it's normal and what we can do to reduce > > it if > > >> it's too high? > > >> > > > From tonyliu0592 at hotmail.com Mon Nov 9 04:41:09 2020 From: tonyliu0592 at hotmail.com (Tony Liu) Date: Mon, 9 Nov 2020 04:41:09 +0000 Subject: openvswitch+dpdk 100% cpu usage of ovs-vswitchd In-Reply-To: References: Message-ID: Bonding is a SW feature supported by either kernel or DPDK layer. In case of SRIOV, it's not complicated to enable bonding inside VM. And it has to be two NICs connecting to two ToRs. Depending on DPDK implementation, you might be able to use VF. Anyways, it's always recommended to have dedicated NIC for SRIOV. Thanks! Tony > -----Original Message----- > From: Satish Patel > Sent: Sunday, November 8, 2020 6:51 PM > To: Tony Liu > Cc: Laurent Dumont ; OpenStack Discuss > > Subject: Re: openvswitch+dpdk 100% cpu usage of ovs-vswitchd > > Thank you tony, > > We are running openstack cloud with SR-IOV and we are happy with > performance but one big issue, it doesn't support bonding on compute > nodes, we can do bonding inside VM but that is over complicated to do > that level of deployment, without bonding it's always risky if tor > switch dies. that is why i started looking into DPDK but look like i hit > the wall again because my compute node has only 2 NIC we i can't do > bonding while i am connected over same nic. Anyway i will stick with SR- > IOV in that case to get more performance and less complexity. > > On Sun, Nov 8, 2020 at 3:22 PM Tony Liu wrote: > > > > SRIOV gives you the maximum performance, without any SW features > > (security group, L3 routing, etc.), because it bypasses SW. > > DPDK gives you less performance, with all SW features. > > > > Depend on the use case, max perf and SW features, you will need to > > make a decision. > > > > > > Tony > > > -----Original Message----- > > > From: Laurent Dumont > > > Sent: Sunday, November 8, 2020 9:04 AM > > > To: Satish Patel > > > Cc: OpenStack Discuss > > > Subject: Re: openvswitch+dpdk 100% cpu usage of ovs-vswitchd > > > > > > I have limited hands-on experience with both but they don't serve > > > the same purpose/have the same implementation. You use SRIOV to > > > allow Tenants to access the NIC cards directly and bypass any > > > inherent linux- vr/OVS performance limitations. This is key for NFV > > > workloads which are expecting large amount of PPS + low latency > > > (because they are often just virtualized bare-metal products with > > > one real cloud- readiness/architecture ;) ) - This means that a > > > Tenant with an SRIOV port can use DPDK + access the NIC through the > > > VF which means (in theory) a better performance than OVS+DPDK. > > > > > > You use ovs-dpdk to increase the performance of OVS based flows (so > > > provider networks + vxlan based internal-tenant networks). > > > > > > On Sun, Nov 8, 2020 at 11:13 AM Satish Patel > > > wrote: > > > > > > > > > Thanks. Just curious then why people directly go for SR-IOV > > > implementation where they get better performance + they can > use the > > > same CPU more also. What are the measure advantages or > features > > > attracting the community to go with DPDK over SR-IOV? > > > > > > On Sun, Nov 8, 2020 at 10:50 AM Laurent Dumont > > > > wrote: > > > > > > > > As far as I know, DPDK enabled cores will show 100% usage at > > > all times. > > > > > > > > On Sun, Nov 8, 2020 at 9:39 AM Satish Patel > > > > wrote: > > > >> > > > >> Folks, > > > >> > > > >> Recently i have added come compute nodes in cloud > supporting > > > >> openvswitch-dpdk for performance. I am seeing all my PMD > > > cpu cores are > > > >> 100% cpu usage on linux top command. It is normal behavior > > > from first > > > >> looks. It's very scary to see 400% cpu usage on top. Can > someone > > > >> confirm before I assume it's normal and what we can do to > > > reduce it if > > > >> it's too high? > > > >> > > > > > From skaplons at redhat.com Mon Nov 9 07:36:28 2020 From: skaplons at redhat.com (Slawek Kaplonski) Date: Mon, 09 Nov 2020 08:36:28 +0100 Subject: [neutron] Use the same network interface with multiple ML2 mechanism drivers In-Reply-To: References: Message-ID: <5309547.V514dPugnQ@p1> Hi, Dnia niedziela, 8 listopada 2020 04:06:50 CET Gabriel Omar Gamero Montenegro pisze: > Dear all, > > I know that ML2 Neutron core plugin is designed to > support multiple mechanism and type drivers simultaneously. > But I'd like to know: is it possible to use the > same network interface configured with different > ML2 mechanism drivers? > > I'm planning to use openvswitch and linuxbridge as > mechanism drivers along with VLAN as type driver. > Could it be possible to have the following > configuration for that purpose?: > > ml2_conf.ini: > [ml2] > mechanism_drivers = openvswitch,linuxbridge > [ml2_type_vlan] > network_vlan_ranges = physnet1:40:60,physnet2:60:80 > > eth3 is a port of the provider bridge: > ovs-vsctl add-port br-provider eth3 > > openvswitch_agent.ini: > [ovs] > bridge_mappings = physnet1:br-provider > > linuxbridge_agent.ini: > [linux_bridge] > physical_interface_mappings = physnet2:eth3 > I don't think it's will work because You would need to have same interface in the ovs bridge (br-provider) and use it by linuxbridge. But TBH this is a bit strange configuration for me. I can imaging different computes which are using different backends. But why You want to use linuxbridge and openvswitch agents together on same compute node? > If it's mandatory to use different network interfaces > any guide or sample reference about implementing > multiple mechanism drivers would be highly appreciated. > > Thanks in advance, > Gabriel Gamero -- Slawek Kaplonski Principal Software Engineer Red Hat From ionut at fleio.com Mon Nov 9 10:30:11 2020 From: ionut at fleio.com (Ionut Biru) Date: Mon, 9 Nov 2020 12:30:11 +0200 Subject: [magnum] heat-container-agent:victoria-dev In-Reply-To: References: Message-ID: Hi, I tried to run manually from inside the heat container the same commands and they worked fine. I think it doesn't inherit the values from /etc/bashrc On Fri, Nov 6, 2020 at 2:40 PM Ionut Biru wrote: > Hi, > > yes, it's deployed: https://paste.xinu.at/pEz/#n855 > > On Fri, Nov 6, 2020 at 2:36 PM Spyros Trigazis wrote: > >> Check if you have this patch deployed: >> https://review.opendev.org/#/q/I15ef91bbec20a8037d47902225eabb3082579705 >> >> On Fri, Nov 6, 2020 at 1:03 PM Ionut Biru wrote: >> >>> Hi, >>> >>> I wonder if it is because the image is from fedora:rawhide and something >>> is too new in there and breaks the flow? >>> >>> https://opendev.org/openstack/magnum/commit/1de7a6af5ee2b834360e3daba34adb6b908fa035 >>> >>> >>> On Fri, Nov 6, 2020 at 1:34 PM Ionut Biru wrote: >>> >>>> Hi, >>>> >>>> I'm using stable/victoria. It works fine with an older image. >>>> >>>> On Fri, Nov 6, 2020 at 1:28 PM Spyros Trigazis >>>> wrote: >>>> >>>>> I see, this says kubectl misconfigured not missing. >>>>> error: Missing or incomplete configuration info. Please point to an >>>>> existing, complete config file: >>>>> >>>>> I guess you miss some patches: >>>>> https://review.opendev.org/#/q/I15ef91bbec20a8037d47902225eabb3082579705 >>>>> >>>>> Try using an older image of the agent or take the patch above. >>>>> >>>>> Spyros >>>>> >>>>> On Fri, Nov 6, 2020 at 12:01 PM Ionut Biru wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Not sure if because kubectl is not found but here are the logs, I >>>>>> cannot figure out why it is not working with the new heat image. >>>>>> >>>>>> journalctl https://paste.xinu.at/jsA/ >>>>>> heat-config master https://paste.xinu.at/pEz/ >>>>>> heat-config master cluster config https://paste.xinu.at/K85ZY5/ >>>>>> >>>>>> [root at cluster001-7dby23lm6ods-master-0 heat-config-script]# kubectl >>>>>> get pods --all-namespaces >>>>>> No resources found >>>>>> [root at cluster001-7dby23lm6ods-master-0 heat-config-script]# kubectl >>>>>> get all --all-namespaces >>>>>> NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP >>>>>> PORT(S) AGE >>>>>> default service/kubernetes ClusterIP 10.254.0.1 >>>>>> 443/TCP 36m >>>>>> >>>>>> It fails to deploy and I don't have any services configured. >>>>>> >>>>>> On Fri, Nov 6, 2020 at 12:43 PM Spyros Trigazis >>>>>> wrote: >>>>>> >>>>>>> Am I missing something? It is there. >>>>>>> >>>>>>> Spyros >>>>>>> >>>>>>> ubuntu at str-focal-2xlarge-01:~$ docker run -it --entrypoint >>>>>>> /usr/bin/kubectl openstackmagnum/heat-container-agent:victoria-dev version >>>>>>> --client --short >>>>>>> Client Version: v1.18.2 >>>>>>> ubuntu at str-focal-2xlarge-01:~$ docker run -it --entrypoint >>>>>>> /usr/bin/kubectl openstackmagnum/heat-container-agent at sha256:0f354341b1970b7dacd9825a1c7585bae5495842416123941965574374922b51 >>>>>>> version --client --short >>>>>>> Client Version: v1.18.2 >>>>>>> >>>>>>> On Fri, Nov 6, 2020 at 11:33 AM Ionut Biru wrote: >>>>>>> >>>>>>>> I wanted to say, 20 hours ago instead of days. >>>>>>>> >>>>>>>> On Fri, Nov 6, 2020 at 12:33 PM Ionut Biru wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> 20 days ago the image was updated and now all clusters fail to >>>>>>>>> deploy because it cannot find >>>>>>>>> /usr/bin/kubectl, i think. >>>>>>>>> >>>>>>>>> /usr/bin/kubectl apply -f >>>>>>>>> /srv/magnum/kubernetes/manifests/calico-deploy.yaml --namespace=kube-system >>>>>>>>> >>>>>>>>> Some services are installed using full path instead of simply >>>>>>>>> kubectl. >>>>>>>>> >>>>>>>>> Should the image be fixed or reverted the changes to old revision >>>>>>>>> or we should just fix the scripts? >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Ionut Biru - https://fleio.com >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Ionut Biru - https://fleio.com >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Ionut Biru - https://fleio.com >>>>>> >>>>> >>>> >>>> -- >>>> Ionut Biru - https://fleio.com >>>> >>> >>> >>> -- >>> Ionut Biru - https://fleio.com >>> >> > > -- > Ionut Biru - https://fleio.com > -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From strigazi at gmail.com Mon Nov 9 10:43:10 2020 From: strigazi at gmail.com (Spyros Trigazis) Date: Mon, 9 Nov 2020 11:43:10 +0100 Subject: [magnum] heat-container-agent:victoria-dev In-Reply-To: References: Message-ID: Please follow/comment https://storyboard.openstack.org/#!/story/2007591 Thanks, Spyros On Mon, Nov 9, 2020 at 11:30 AM Ionut Biru wrote: > Hi, > > I tried to run manually from inside the heat container the same commands > and they worked fine. > > I think it doesn't inherit the values from /etc/bashrc > > On Fri, Nov 6, 2020 at 2:40 PM Ionut Biru wrote: > >> Hi, >> >> yes, it's deployed: https://paste.xinu.at/pEz/#n855 >> >> On Fri, Nov 6, 2020 at 2:36 PM Spyros Trigazis >> wrote: >> >>> Check if you have this patch deployed: >>> https://review.opendev.org/#/q/I15ef91bbec20a8037d47902225eabb3082579705 >>> >>> On Fri, Nov 6, 2020 at 1:03 PM Ionut Biru wrote: >>> >>>> Hi, >>>> >>>> I wonder if it is because the image is from fedora:rawhide and >>>> something is too new in there and breaks the flow? >>>> >>>> https://opendev.org/openstack/magnum/commit/1de7a6af5ee2b834360e3daba34adb6b908fa035 >>>> >>>> >>>> On Fri, Nov 6, 2020 at 1:34 PM Ionut Biru wrote: >>>> >>>>> Hi, >>>>> >>>>> I'm using stable/victoria. It works fine with an older image. >>>>> >>>>> On Fri, Nov 6, 2020 at 1:28 PM Spyros Trigazis >>>>> wrote: >>>>> >>>>>> I see, this says kubectl misconfigured not missing. >>>>>> error: Missing or incomplete configuration info. Please point to an >>>>>> existing, complete config file: >>>>>> >>>>>> I guess you miss some patches: >>>>>> https://review.opendev.org/#/q/I15ef91bbec20a8037d47902225eabb3082579705 >>>>>> >>>>>> Try using an older image of the agent or take the patch above. >>>>>> >>>>>> Spyros >>>>>> >>>>>> On Fri, Nov 6, 2020 at 12:01 PM Ionut Biru wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Not sure if because kubectl is not found but here are the logs, I >>>>>>> cannot figure out why it is not working with the new heat image. >>>>>>> >>>>>>> journalctl https://paste.xinu.at/jsA/ >>>>>>> heat-config master https://paste.xinu.at/pEz/ >>>>>>> heat-config master cluster config https://paste.xinu.at/K85ZY5/ >>>>>>> >>>>>>> [root at cluster001-7dby23lm6ods-master-0 heat-config-script]# kubectl >>>>>>> get pods --all-namespaces >>>>>>> No resources found >>>>>>> [root at cluster001-7dby23lm6ods-master-0 heat-config-script]# kubectl >>>>>>> get all --all-namespaces >>>>>>> NAMESPACE NAME TYPE CLUSTER-IP >>>>>>> EXTERNAL-IP PORT(S) AGE >>>>>>> default service/kubernetes ClusterIP 10.254.0.1 >>>>>>> 443/TCP 36m >>>>>>> >>>>>>> It fails to deploy and I don't have any services configured. >>>>>>> >>>>>>> On Fri, Nov 6, 2020 at 12:43 PM Spyros Trigazis >>>>>>> wrote: >>>>>>> >>>>>>>> Am I missing something? It is there. >>>>>>>> >>>>>>>> Spyros >>>>>>>> >>>>>>>> ubuntu at str-focal-2xlarge-01:~$ docker run -it --entrypoint >>>>>>>> /usr/bin/kubectl openstackmagnum/heat-container-agent:victoria-dev version >>>>>>>> --client --short >>>>>>>> Client Version: v1.18.2 >>>>>>>> ubuntu at str-focal-2xlarge-01:~$ docker run -it --entrypoint >>>>>>>> /usr/bin/kubectl openstackmagnum/heat-container-agent at sha256:0f354341b1970b7dacd9825a1c7585bae5495842416123941965574374922b51 >>>>>>>> version --client --short >>>>>>>> Client Version: v1.18.2 >>>>>>>> >>>>>>>> On Fri, Nov 6, 2020 at 11:33 AM Ionut Biru wrote: >>>>>>>> >>>>>>>>> I wanted to say, 20 hours ago instead of days. >>>>>>>>> >>>>>>>>> On Fri, Nov 6, 2020 at 12:33 PM Ionut Biru >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> 20 days ago the image was updated and now all clusters fail to >>>>>>>>>> deploy because it cannot find >>>>>>>>>> /usr/bin/kubectl, i think. >>>>>>>>>> >>>>>>>>>> /usr/bin/kubectl apply -f >>>>>>>>>> /srv/magnum/kubernetes/manifests/calico-deploy.yaml --namespace=kube-system >>>>>>>>>> >>>>>>>>>> Some services are installed using full path instead of simply >>>>>>>>>> kubectl. >>>>>>>>>> >>>>>>>>>> Should the image be fixed or reverted the changes to old revision >>>>>>>>>> or we should just fix the scripts? >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Ionut Biru - https://fleio.com >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Ionut Biru - https://fleio.com >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Ionut Biru - https://fleio.com >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Ionut Biru - https://fleio.com >>>>> >>>> >>>> >>>> -- >>>> Ionut Biru - https://fleio.com >>>> >>> >> >> -- >> Ionut Biru - https://fleio.com >> > > > -- > Ionut Biru - https://fleio.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry at openstack.org Mon Nov 9 10:44:23 2020 From: thierry at openstack.org (Thierry Carrez) Date: Mon, 9 Nov 2020 11:44:23 +0100 Subject: [largescale-sig] Future meeting time In-Reply-To: <580916f8-dd2e-fbca-56e4-b3ae0dfca85d@openstack.org> References: <580916f8-dd2e-fbca-56e4-b3ae0dfca85d@openstack.org> Message-ID: Thierry Carrez wrote: > During the PTG we discussed our meeting time. Currently we are rotating > every two weeks between a APAC-EU friendly time (8utc) and a EU-US > friendly time (16utc). However, rotating the meeting between two > timezones resulted in fragmenting the already-small group, with only > Europeans being regular attendees. > > After discussing this at the PTG with Gene Kuo, we think it's easier to > have a single meeting time, if we can find one that works for all active > members. > > Please enter your preferences into this date poll for Wednesday times: > https://framadate.org/ue2eOBTT3QXoFhKg > > Feel free to add comments pointing to better times for you, like other > days that would work better for you than Wednesdays for example. Thanks to all those who responded, I selected Wednesdays at 14UTC for our Wallaby cycle meetings. Next meeting will be next week, Nov 18. mark your calendars ! -- Thierry Carrez (ttx) From mark at stackhpc.com Mon Nov 9 10:44:51 2020 From: mark at stackhpc.com (Mark Goddard) Date: Mon, 9 Nov 2020 10:44:51 +0000 Subject: [kolla] IRC meeting cancelled on 11th November Message-ID: Hi, Since I and a number of cores are away on Wednesday 11th November, let's cancel the IRC meeting. The focus should be on continuing to stabilise the Victoria release. Thanks, Mark From mark at stackhpc.com Mon Nov 9 11:33:50 2020 From: mark at stackhpc.com (Mark Goddard) Date: Mon, 9 Nov 2020 11:33:50 +0000 Subject: [kolla] Proposing wu.chunyang for Kolla core Message-ID: Hi, I would like to propose adding wu.chunyang to the kolla-core and kolla-ansible-core groups. wu.chunyang did some great work on Octavia integration in the Victoria release, and has provided some helpful reviews. Cores - please reply +1/-1 before the end of Friday 13th November. Thanks, Mark From marcin.juszkiewicz at linaro.org Mon Nov 9 11:35:56 2020 From: marcin.juszkiewicz at linaro.org (Marcin Juszkiewicz) Date: Mon, 9 Nov 2020 12:35:56 +0100 Subject: [kolla] Proposing wu.chunyang for Kolla core In-Reply-To: References: Message-ID: W dniu 09.11.2020 o 12:33, Mark Goddard pisze: > Hi, > > I would like to propose adding wu.chunyang to the kolla-core and > kolla-ansible-core groups. wu.chunyang did some great work on Octavia > integration in the Victoria release, and has provided some helpful > reviews. > > Cores - please reply +1/-1 before the end of Friday 13th November. +1 From ionut at fleio.com Mon Nov 9 11:40:13 2020 From: ionut at fleio.com (Ionut Biru) Date: Mon, 9 Nov 2020 13:40:13 +0200 Subject: [magnum] heat-container-agent:victoria-dev In-Reply-To: References: Message-ID: Hi, Thanks for pointing out the story, It help me to fix it. Please review: https://review.opendev.org/#/c/761897/ On Mon, Nov 9, 2020 at 12:43 PM Spyros Trigazis wrote: > Please follow/comment https://storyboard.openstack.org/#!/story/2007591 > > Thanks, > Spyros > > On Mon, Nov 9, 2020 at 11:30 AM Ionut Biru wrote: > >> Hi, >> >> I tried to run manually from inside the heat container the same commands >> and they worked fine. >> >> I think it doesn't inherit the values from /etc/bashrc >> >> On Fri, Nov 6, 2020 at 2:40 PM Ionut Biru wrote: >> >>> Hi, >>> >>> yes, it's deployed: https://paste.xinu.at/pEz/#n855 >>> >>> On Fri, Nov 6, 2020 at 2:36 PM Spyros Trigazis >>> wrote: >>> >>>> Check if you have this patch deployed: >>>> https://review.opendev.org/#/q/I15ef91bbec20a8037d47902225eabb3082579705 >>>> >>>> On Fri, Nov 6, 2020 at 1:03 PM Ionut Biru wrote: >>>> >>>>> Hi, >>>>> >>>>> I wonder if it is because the image is from fedora:rawhide and >>>>> something is too new in there and breaks the flow? >>>>> >>>>> https://opendev.org/openstack/magnum/commit/1de7a6af5ee2b834360e3daba34adb6b908fa035 >>>>> >>>>> >>>>> On Fri, Nov 6, 2020 at 1:34 PM Ionut Biru wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I'm using stable/victoria. It works fine with an older image. >>>>>> >>>>>> On Fri, Nov 6, 2020 at 1:28 PM Spyros Trigazis >>>>>> wrote: >>>>>> >>>>>>> I see, this says kubectl misconfigured not missing. >>>>>>> error: Missing or incomplete configuration info. Please point to an >>>>>>> existing, complete config file: >>>>>>> >>>>>>> I guess you miss some patches: >>>>>>> https://review.opendev.org/#/q/I15ef91bbec20a8037d47902225eabb3082579705 >>>>>>> >>>>>>> Try using an older image of the agent or take the patch above. >>>>>>> >>>>>>> Spyros >>>>>>> >>>>>>> On Fri, Nov 6, 2020 at 12:01 PM Ionut Biru wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Not sure if because kubectl is not found but here are the logs, I >>>>>>>> cannot figure out why it is not working with the new heat image. >>>>>>>> >>>>>>>> journalctl https://paste.xinu.at/jsA/ >>>>>>>> heat-config master https://paste.xinu.at/pEz/ >>>>>>>> heat-config master cluster config https://paste.xinu.at/K85ZY5/ >>>>>>>> >>>>>>>> [root at cluster001-7dby23lm6ods-master-0 heat-config-script]# >>>>>>>> kubectl get pods --all-namespaces >>>>>>>> No resources found >>>>>>>> [root at cluster001-7dby23lm6ods-master-0 heat-config-script]# >>>>>>>> kubectl get all --all-namespaces >>>>>>>> NAMESPACE NAME TYPE CLUSTER-IP >>>>>>>> EXTERNAL-IP PORT(S) AGE >>>>>>>> default service/kubernetes ClusterIP 10.254.0.1 >>>>>>>> 443/TCP 36m >>>>>>>> >>>>>>>> It fails to deploy and I don't have any services configured. >>>>>>>> >>>>>>>> On Fri, Nov 6, 2020 at 12:43 PM Spyros Trigazis >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Am I missing something? It is there. >>>>>>>>> >>>>>>>>> Spyros >>>>>>>>> >>>>>>>>> ubuntu at str-focal-2xlarge-01:~$ docker run -it --entrypoint >>>>>>>>> /usr/bin/kubectl openstackmagnum/heat-container-agent:victoria-dev version >>>>>>>>> --client --short >>>>>>>>> Client Version: v1.18.2 >>>>>>>>> ubuntu at str-focal-2xlarge-01:~$ docker run -it --entrypoint >>>>>>>>> /usr/bin/kubectl openstackmagnum/heat-container-agent at sha256:0f354341b1970b7dacd9825a1c7585bae5495842416123941965574374922b51 >>>>>>>>> version --client --short >>>>>>>>> Client Version: v1.18.2 >>>>>>>>> >>>>>>>>> On Fri, Nov 6, 2020 at 11:33 AM Ionut Biru >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> I wanted to say, 20 hours ago instead of days. >>>>>>>>>> >>>>>>>>>> On Fri, Nov 6, 2020 at 12:33 PM Ionut Biru >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> 20 days ago the image was updated and now all clusters fail to >>>>>>>>>>> deploy because it cannot find >>>>>>>>>>> /usr/bin/kubectl, i think. >>>>>>>>>>> >>>>>>>>>>> /usr/bin/kubectl apply -f >>>>>>>>>>> /srv/magnum/kubernetes/manifests/calico-deploy.yaml --namespace=kube-system >>>>>>>>>>> >>>>>>>>>>> Some services are installed using full path instead of simply >>>>>>>>>>> kubectl. >>>>>>>>>>> >>>>>>>>>>> Should the image be fixed or reverted the changes to old >>>>>>>>>>> revision or we should just fix the scripts? >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Ionut Biru - https://fleio.com >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Ionut Biru - https://fleio.com >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Ionut Biru - https://fleio.com >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Ionut Biru - https://fleio.com >>>>>> >>>>> >>>>> >>>>> -- >>>>> Ionut Biru - https://fleio.com >>>>> >>>> >>> >>> -- >>> Ionut Biru - https://fleio.com >>> >> >> >> -- >> Ionut Biru - https://fleio.com >> > -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Mon Nov 9 12:12:38 2020 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Mon, 9 Nov 2020 13:12:38 +0100 Subject: [kolla] Proposing wu.chunyang for Kolla core In-Reply-To: References: Message-ID: On Mon, Nov 9, 2020 at 12:34 PM Mark Goddard wrote: > > Hi, > > I would like to propose adding wu.chunyang to the kolla-core and > kolla-ansible-core groups. wu.chunyang did some great work on Octavia > integration in the Victoria release, and has provided some helpful > reviews. > > Cores - please reply +1/-1 before the end of Friday 13th November. +1 From mnasiadka at gmail.com Mon Nov 9 12:21:52 2020 From: mnasiadka at gmail.com (=?UTF-8?Q?Micha=C5=82_Nasiadka?=) Date: Mon, 9 Nov 2020 13:21:52 +0100 Subject: [kolla] Proposing wu.chunyang for Kolla core In-Reply-To: References: Message-ID: +1 pon., 9 lis 2020 o 12:35 Mark Goddard napisał(a): > Hi, > > I would like to propose adding wu.chunyang to the kolla-core and > kolla-ansible-core groups. wu.chunyang did some great work on Octavia > integration in the Victoria release, and has provided some helpful > reviews. > > Cores - please reply +1/-1 before the end of Friday 13th November. > > Thanks, > Mark > > -- Michał Nasiadka mnasiadka at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Mon Nov 9 13:25:25 2020 From: smooney at redhat.com (Sean Mooney) Date: Mon, 09 Nov 2020 13:25:25 +0000 Subject: openvswitch+dpdk 100% cpu usage of ovs-vswitchd In-Reply-To: References: Message-ID: <7b6c8fa04ea74598ba2a9d365f1ac72aee8f872c.camel@redhat.com> On Sun, 2020-11-08 at 09:31 -0500, Satish Patel wrote: > Folks, > > Recently i have added come compute nodes in cloud supporting > openvswitch-dpdk for performance. I am seeing all my PMD cpu cores are > 100% cpu usage on linux top command. yes this is perfectly normal and how dpdk is intended to work PMD stands for pool mode driver. the dpdk driver is runing in a busy loop polling the nic for new packets to process so form a linux perspective the core wil be used 100%. dpdk has its own stats for pmd useage that tell you the actul capasity but thre is nothing to be alarmed by. > It is normal behavior from first > looks. It's very scary to see 400% cpu usage on top. Can someone > confirm before I assume it's normal and what we can do to reduce it if > it's too high? > From fungi at yuggoth.org Mon Nov 9 13:48:18 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 9 Nov 2020 13:48:18 +0000 Subject: [Release-job-failures] Release of openstack/ansible-role-redhat-subscription for ref refs/tags/1.1.1 failed In-Reply-To: <20201106175052.7v3iwde5aw43xuy4@yuggoth.org> References: <642745d9-ca22-3830-c9d1-36f3e97a458d@openstack.org> <20201106173521.3xmgzwoqs2s4hkep@yuggoth.org> <20201106175052.7v3iwde5aw43xuy4@yuggoth.org> Message-ID: <20201109134818.sj75rxdurliuvq5k@yuggoth.org> On 2020-11-06 17:50:52 +0000 (+0000), Jeremy Stanley wrote: > On 2020-11-06 17:35:21 +0000 (+0000), Jeremy Stanley wrote: > [...] > > I propose we switch release jobs to run on an ubuntu-focal nodeset, > > as most official OpenStack jobs did already during the Victoria > > cycle. > [...] > > Now up for review: https://review.opendev.org/761776 This seems to have solved the problem. We also observed successful releases for the nova repository, including stable point releases for stable/stein and stable/train, so this presumably hasn't broken more common cases. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From smooney at redhat.com Mon Nov 9 14:03:06 2020 From: smooney at redhat.com (Sean Mooney) Date: Mon, 09 Nov 2020 14:03:06 +0000 Subject: openvswitch+dpdk 100% cpu usage of ovs-vswitchd In-Reply-To: References: Message-ID: <5d30d8f4a6cc6ea92c004f685d1e4501700cae80.camel@redhat.com> On Mon, 2020-11-09 at 04:41 +0000, Tony Liu wrote: > Bonding is a SW feature supported by either kernel or DPDK layer. > In case of SRIOV, it's not complicated to enable bonding inside VM. > And it has to be two NICs connecting to two ToRs. > > Depending on DPDK implementation, you might be able to use VF. > Anyways, it's always recommended to have dedicated NIC for SRIOV. for what its worth melonox do support bondign fo VF on the same card i have never used it but bonding on the host is possibel for sriov. im not sure if it works with openstack however but i belvie it does. you will have to reach out to mellonox to determin if it is. most other nic vendors do not support bonding and it may limit other feature like bandwith based schduling as really you can only list one of the interfaces bandwith because you cant contol which interface is activly being used. > > > Thanks! > Tony > > -----Original Message----- > > From: Satish Patel > > Sent: Sunday, November 8, 2020 6:51 PM > > To: Tony Liu > > Cc: Laurent Dumont ; OpenStack Discuss > > > > Subject: Re: openvswitch+dpdk 100% cpu usage of ovs-vswitchd > > > > Thank you tony, > > > > We are running openstack cloud with SR-IOV and we are happy with > > performance but one big issue, it doesn't support bonding on compute > > nodes, we can do bonding inside VM but that is over complicated to do > > that level of deployment, without bonding it's always risky if tor > > switch dies. that is why i started looking into DPDK but look like i hit > > the wall again because my compute node has only 2 NIC we i can't do > > bonding while i am connected over same nic. Anyway i will stick with SR- > > IOV in that case to get more performance and less complexity. > > > > On Sun, Nov 8, 2020 at 3:22 PM Tony Liu wrote: > > > > > > SRIOV gives you the maximum performance, without any SW features > > > (security group, L3 routing, etc.), because it bypasses SW. > > > DPDK gives you less performance, with all SW features. > > > > > > Depend on the use case, max perf and SW features, you will need to > > > make a decision. > > > > > > > > > Tony > > > > -----Original Message----- > > > > From: Laurent Dumont > > > > Sent: Sunday, November 8, 2020 9:04 AM > > > > To: Satish Patel > > > > Cc: OpenStack Discuss > > > > Subject: Re: openvswitch+dpdk 100% cpu usage of ovs-vswitchd > > > > > > > > I have limited hands-on experience with both but they don't serve > > > > the same purpose/have the same implementation. You use SRIOV to > > > > allow Tenants to access the NIC cards directly and bypass any > > > > inherent linux- vr/OVS performance limitations. This is key for NFV > > > > workloads which are expecting large amount of PPS + low latency > > > > (because they are often just virtualized bare-metal products with > > > > one real cloud- readiness/architecture ;) ) - This means that a > > > > Tenant with an SRIOV port can use DPDK + access the NIC through the > > > > VF which means (in theory) a better performance than OVS+DPDK. > > > > > > > > You use ovs-dpdk to increase the performance of OVS based flows (so > > > > provider networks + vxlan based internal-tenant networks). > > > > > > > > On Sun, Nov 8, 2020 at 11:13 AM Satish Patel > > > > wrote: > > > > > > > > > > > >        Thanks. Just curious then why people directly go for SR-IOV > > > >       implementation where they get better performance + they can > > use the > > > >       same CPU more also. What are the measure advantages or > > features > > > >       attracting the community to go with DPDK over SR-IOV? > > > > > > > >       On Sun, Nov 8, 2020 at 10:50 AM Laurent Dumont > > > > > wrote: > > > >       > > > > >       > As far as I know, DPDK enabled cores will show 100% usage at > > > > all times. > > > >       > > > > >       > On Sun, Nov 8, 2020 at 9:39 AM Satish Patel > > > > > wrote: > > > >       >> > > > >       >> Folks, > > > >       >> > > > >       >> Recently i have added come compute nodes in cloud > > supporting > > > >       >> openvswitch-dpdk for performance. I am seeing all my PMD > > > > cpu cores are > > > >       >> 100% cpu usage on linux top command. It is normal behavior > > > > from first > > > >       >> looks. It's very scary to see 400% cpu usage on top. Can > > someone > > > >       >> confirm before I assume it's normal and what we can do to > > > > reduce it if > > > >       >> it's too high? > > > >       >> > > > > > > > From satish.txt at gmail.com Mon Nov 9 14:13:44 2020 From: satish.txt at gmail.com (Satish Patel) Date: Mon, 9 Nov 2020 09:13:44 -0500 Subject: openvswitch+dpdk 100% cpu usage of ovs-vswitchd In-Reply-To: <5d30d8f4a6cc6ea92c004f685d1e4501700cae80.camel@redhat.com> References: <5d30d8f4a6cc6ea92c004f685d1e4501700cae80.camel@redhat.com> Message-ID: Thank Sean, I have Intel NIC [root at infra-lxb-1 ~]# lspci | grep -i eth 06:00.0 Ethernet controller: Intel Corporation 82599 10 Gigabit Dual Port Backplane Connection (rev 01) 06:00.1 Ethernet controller: Intel Corporation 82599 10 Gigabit Dual Port Backplane Connection (rev 01) I was thinking if i can create a couple VF out of SR-IOV interface and on a computer machine i create two bonding interfaces. bond-1 for mgmt and bond-2 for OVS+DPDK then it will solve my all problem related TOR switches redundancy. I don't think we can add VF as an interface in OVS for DPDK. On Mon, Nov 9, 2020 at 9:03 AM Sean Mooney wrote: > > On Mon, 2020-11-09 at 04:41 +0000, Tony Liu wrote: > > Bonding is a SW feature supported by either kernel or DPDK layer. > > In case of SRIOV, it's not complicated to enable bonding inside VM. > > And it has to be two NICs connecting to two ToRs. > > > > Depending on DPDK implementation, you might be able to use VF. > > Anyways, it's always recommended to have dedicated NIC for SRIOV. > for what its worth melonox do support bondign fo VF on the same card > i have never used it but bonding on the host is possibel for sriov. > im not sure if it works with openstack however but i belvie it does. > > you will have to reach out to mellonox to determin if it is. > most other nic vendors do not support bonding and it may limit other > feature like bandwith based schduling as really you can only list one of the interfaces bandwith > because you cant contol which interface is activly being used. > > > > > > > Thanks! > > Tony > > > -----Original Message----- > > > From: Satish Patel > > > Sent: Sunday, November 8, 2020 6:51 PM > > > To: Tony Liu > > > Cc: Laurent Dumont ; OpenStack Discuss > > > > > > Subject: Re: openvswitch+dpdk 100% cpu usage of ovs-vswitchd > > > > > > Thank you tony, > > > > > > We are running openstack cloud with SR-IOV and we are happy with > > > performance but one big issue, it doesn't support bonding on compute > > > nodes, we can do bonding inside VM but that is over complicated to do > > > that level of deployment, without bonding it's always risky if tor > > > switch dies. that is why i started looking into DPDK but look like i hit > > > the wall again because my compute node has only 2 NIC we i can't do > > > bonding while i am connected over same nic. Anyway i will stick with SR- > > > IOV in that case to get more performance and less complexity. > > > > > > On Sun, Nov 8, 2020 at 3:22 PM Tony Liu wrote: > > > > > > > > SRIOV gives you the maximum performance, without any SW features > > > > (security group, L3 routing, etc.), because it bypasses SW. > > > > DPDK gives you less performance, with all SW features. > > > > > > > > Depend on the use case, max perf and SW features, you will need to > > > > make a decision. > > > > > > > > > > > > Tony > > > > > -----Original Message----- > > > > > From: Laurent Dumont > > > > > Sent: Sunday, November 8, 2020 9:04 AM > > > > > To: Satish Patel > > > > > Cc: OpenStack Discuss > > > > > Subject: Re: openvswitch+dpdk 100% cpu usage of ovs-vswitchd > > > > > > > > > > I have limited hands-on experience with both but they don't serve > > > > > the same purpose/have the same implementation. You use SRIOV to > > > > > allow Tenants to access the NIC cards directly and bypass any > > > > > inherent linux- vr/OVS performance limitations. This is key for NFV > > > > > workloads which are expecting large amount of PPS + low latency > > > > > (because they are often just virtualized bare-metal products with > > > > > one real cloud- readiness/architecture ;) ) - This means that a > > > > > Tenant with an SRIOV port can use DPDK + access the NIC through the > > > > > VF which means (in theory) a better performance than OVS+DPDK. > > > > > > > > > > You use ovs-dpdk to increase the performance of OVS based flows (so > > > > > provider networks + vxlan based internal-tenant networks). > > > > > > > > > > On Sun, Nov 8, 2020 at 11:13 AM Satish Patel > > > > > wrote: > > > > > > > > > > > > > > > Thanks. Just curious then why people directly go for SR-IOV > > > > > implementation where they get better performance + they can > > > use the > > > > > same CPU more also. What are the measure advantages or > > > features > > > > > attracting the community to go with DPDK over SR-IOV? > > > > > > > > > > On Sun, Nov 8, 2020 at 10:50 AM Laurent Dumont > > > > > > wrote: > > > > > > > > > > > > As far as I know, DPDK enabled cores will show 100% usage at > > > > > all times. > > > > > > > > > > > > On Sun, Nov 8, 2020 at 9:39 AM Satish Patel > > > > > > wrote: > > > > > >> > > > > > >> Folks, > > > > > >> > > > > > >> Recently i have added come compute nodes in cloud > > > supporting > > > > > >> openvswitch-dpdk for performance. I am seeing all my PMD > > > > > cpu cores are > > > > > >> 100% cpu usage on linux top command. It is normal behavior > > > > > from first > > > > > >> looks. It's very scary to see 400% cpu usage on top. Can > > > someone > > > > > >> confirm before I assume it's normal and what we can do to > > > > > reduce it if > > > > > >> it's too high? > > > > > >> > > > > > > > > > > > From hberaud at redhat.com Mon Nov 9 14:17:00 2020 From: hberaud at redhat.com (Herve Beraud) Date: Mon, 9 Nov 2020 15:17:00 +0100 Subject: [Release-job-failures] Release of openstack/ansible-role-redhat-subscription for ref refs/tags/1.1.1 failed In-Reply-To: <20201109134818.sj75rxdurliuvq5k@yuggoth.org> References: <642745d9-ca22-3830-c9d1-36f3e97a458d@openstack.org> <20201106173521.3xmgzwoqs2s4hkep@yuggoth.org> <20201106175052.7v3iwde5aw43xuy4@yuggoth.org> <20201109134818.sj75rxdurliuvq5k@yuggoth.org> Message-ID: >From the release management side I confirm that this fix solved the problem, ansible-role-redhat-subscription 1.1.1 have been re-enqueued and successfully released on pypi [1]. Thanks Jeremy for all things done on this topic. [1] https://pypi.org/project/ansible-role-redhat-subscription/#history Le lun. 9 nov. 2020 à 14:52, Jeremy Stanley a écrit : > On 2020-11-06 17:50:52 +0000 (+0000), Jeremy Stanley wrote: > > On 2020-11-06 17:35:21 +0000 (+0000), Jeremy Stanley wrote: > > [...] > > > I propose we switch release jobs to run on an ubuntu-focal nodeset, > > > as most official OpenStack jobs did already during the Victoria > > > cycle. > > [...] > > > > Now up for review: https://review.opendev.org/761776 > > This seems to have solved the problem. We also observed successful > releases for the nova repository, including stable point releases > for stable/stein and stable/train, so this presumably hasn't broken > more common cases. > -- > Jeremy Stanley > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From gabriel.gamero at pucp.edu.pe Mon Nov 9 14:24:57 2020 From: gabriel.gamero at pucp.edu.pe (Gabriel Omar Gamero Montenegro) Date: Mon, 9 Nov 2020 09:24:57 -0500 Subject: [neutron] Use the same network interface with multiple ML2 mechanism drivers In-Reply-To: <5309547.V514dPugnQ@p1> References: <5309547.V514dPugnQ@p1> Message-ID: I'm planning to deploy OpenStack with 2 mechanism drivers on physical servers with only one network interface card: openvswitch and SR-IOV. According to what I read, it is possible to use the same physical interface using these 2 mechanism drivers. I assume this is possible because a NIC with SR-IOV capabilities can divide a NIC into a PhysicalFunction (which I'm using for openvswitch) and many VirtualFunctions (which I'm using for SR-IOV). Before editing something on physical servers I was planning to use a test environment with virtual machines where I do not count with a NIC with SR-IOV capabilities. Since the mechanism driver of openvswitch will work with security groups and the SR-IOV mechanism driver can't have security groups enabled, I was planning to use linux bridge as a replacement and disable the security feature. Thus, I can make security tests with a SDN module that I'm developing for networks with SR-IOV in OpenStack. Thanks. Gabriel Gamero. El lun., 9 nov. 2020 a las 2:36, Slawek Kaplonski () escribió: > > Hi, > > Dnia niedziela, 8 listopada 2020 04:06:50 CET Gabriel Omar Gamero Montenegro > pisze: > > Dear all, > > > > I know that ML2 Neutron core plugin is designed to > > support multiple mechanism and type drivers simultaneously. > > But I'd like to know: is it possible to use the > > same network interface configured with different > > ML2 mechanism drivers? > > > > I'm planning to use openvswitch and linuxbridge as > > mechanism drivers along with VLAN as type driver. > > Could it be possible to have the following > > configuration for that purpose?: > > > > ml2_conf.ini: > > [ml2] > > mechanism_drivers = openvswitch,linuxbridge > > [ml2_type_vlan] > > network_vlan_ranges = physnet1:40:60,physnet2:60:80 > > > > eth3 is a port of the provider bridge: > > ovs-vsctl add-port br-provider eth3 > > > > openvswitch_agent.ini: > > [ovs] > > bridge_mappings = physnet1:br-provider > > > > linuxbridge_agent.ini: > > [linux_bridge] > > physical_interface_mappings = physnet2:eth3 > > > > I don't think it's will work because You would need to have same interface in > the ovs bridge (br-provider) and use it by linuxbridge. > But TBH this is a bit strange configuration for me. I can imaging different > computes which are using different backends. But why You want to use > linuxbridge and openvswitch agents together on same compute node? > > > If it's mandatory to use different network interfaces > > any guide or sample reference about implementing > > multiple mechanism drivers would be highly appreciated. > > > > Thanks in advance, > > Gabriel Gamero > > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat > > From smooney at redhat.com Mon Nov 9 14:28:33 2020 From: smooney at redhat.com (Sean Mooney) Date: Mon, 09 Nov 2020 14:28:33 +0000 Subject: [neutron] Use the same network interface with multiple ML2 mechanism drivers In-Reply-To: <5309547.V514dPugnQ@p1> References: <5309547.V514dPugnQ@p1> Message-ID: On Mon, 2020-11-09 at 08:36 +0100, Slawek Kaplonski wrote: > Hi, > > Dnia niedziela, 8 listopada 2020 04:06:50 CET Gabriel Omar Gamero Montenegro > pisze: > > Dear all, > > > > I know that ML2 Neutron core plugin is designed to > > support multiple mechanism and type drivers simultaneously. > > But I'd like to know: is it possible to use the > > same network interface configured with different > > ML2 mechanism drivers? you can use the sriov nic agent to manage VF and use either the linux bridge agent or ovs agent to managed the pf on the same host. > > > > I'm planning to use openvswitch and linuxbridge as > > mechanism drivers along with VLAN as type driver. > > Could it be possible to have the following > > configuration for that purpose?: > > > > ml2_conf.ini: > > [ml2] > > mechanism_drivers = openvswitch,linuxbridge > > [ml2_type_vlan] > > network_vlan_ranges = physnet1:40:60,physnet2:60:80 > > > > eth3 is a port of the provider bridge: > > ovs-vsctl add-port br-provider eth3 > > > > openvswitch_agent.ini: > > [ovs] > > bridge_mappings = physnet1:br-provider > > > > linuxbridge_agent.ini: > > [linux_bridge] > > physical_interface_mappings = physnet2:eth3 > > > > I don't think it's will work because You would need to have same interface in > the ovs bridge (br-provider) and use it by linuxbridge. > But TBH this is a bit strange configuration for me. I can imaging different > computes which are using different backends. But why You want to use > linuxbridge and openvswitch agents together on same compute node? ya in this case it wont work although there are cases wehre it would. linux bridge is better fro multi cast heavy workslond so you might want all vxlan traffic to be handeled by linux bridge whith all vlan traffic handeled by ovs. > > > If it's mandatory to use different network interfaces > > any guide or sample reference about implementing > > multiple mechanism drivers would be highly appreciated. its really intened to have different ml2 dirver on differnet hosts with one exception. if the vnic types supported by each ml2 driver do not over lap then you can have two different ml2 drivers on the same host. e.g. sriov + somethign else. it should also be noted that mixed deployemtn really only work properly for vlan and flat netwroks. tuneled networks like vxlan will not form the required mesh to allow comunication between host with different backends. if you want to run linux bridge and ovs on the same host you could do it by using 2 nics with different physnets e.g. using eth2 for ovs and eth3 for linux bridge openvswitch_agent.ini: > > [ovs] > > bridge_mappings = ovs-physnet:br-provider added eth2 to br-provider linuxbridge_agent.ini: > > [linux_bridge] > > physical_interface_mappings = linuxbridge-physnet:eth3 tunnesl will only ever be served by one of the 2 ml2 drivers on any one host determined by mechanism_drivers = openvswitch,linuxbridge in this case ovs would be used for all tunnel traffic unless you segreate the vni ranges so that linxu bgride and ovs have different ranges. netuon will still basically allocate networks in assendign order fo vnis so it will file one before using the other as an operator you could specify the vni to use when creating a network but i dont belive that normal users can do that. in general i would not advice doing this and just using 1 ml2 driver for vnic_type=normal on a singel host as it make debuging much much harder and vendors wont generaly support this custom config. its possible to do but you really really need to know how the different backends work. simple is normally better when it comes to networking. > > > > Thanks in advance, > > Gabriel Gamero > > From smooney at redhat.com Mon Nov 9 14:30:34 2020 From: smooney at redhat.com (Sean Mooney) Date: Mon, 09 Nov 2020 14:30:34 +0000 Subject: openvswitch+dpdk 100% cpu usage of ovs-vswitchd In-Reply-To: References: <5d30d8f4a6cc6ea92c004f685d1e4501700cae80.camel@redhat.com> Message-ID: <80aaf9917fb3624b15af3f2119b65c115409d7f1.camel@redhat.com> On Mon, 2020-11-09 at 09:13 -0500, Satish Patel wrote: > Thank Sean, > > I have Intel NIC > > [root at infra-lxb-1 ~]# lspci | grep -i eth > 06:00.0 Ethernet controller: Intel Corporation 82599 10 Gigabit Dual > Port Backplane Connection (rev 01) > 06:00.1 Ethernet controller: Intel Corporation 82599 10 Gigabit Dual > Port Backplane Connection (rev 01) > > I was thinking if i can create a couple VF out of SR-IOV interface and > on a computer machine i create two bonding interfaces. bond-1 for mgmt > and bond-2 for OVS+DPDK then it will solve my all problem related TOR > switches redundancy. > > I don't think we can add VF as an interface in OVS for DPDK. you can and if you create the bond on the host first it basically defeets teh reason for using dpdk the kernel bond driver will be a bottelneck for dpdk. if you want to bond dpdk interfaces then you should create that bond in ovs by adding the two vfs and then creatign an ovs bond. > On Mon, Nov 9, 2020 at 9:03 AM Sean Mooney wrote: > > > > On Mon, 2020-11-09 at 04:41 +0000, Tony Liu wrote: > > > Bonding is a SW feature supported by either kernel or DPDK layer. > > > In case of SRIOV, it's not complicated to enable bonding inside VM. > > > And it has to be two NICs connecting to two ToRs. > > > > > > Depending on DPDK implementation, you might be able to use VF. > > > Anyways, it's always recommended to have dedicated NIC for SRIOV. > > for what its worth melonox do support bondign fo VF on the same card > > i have never used it but bonding on the host is possibel for sriov. > > im not sure if it works with openstack however but i belvie it does. > > > > you will have to reach out to mellonox to determin if it is. > > most other nic vendors do not support bonding and it may limit other > > feature like bandwith based schduling as really you can only list one of the interfaces bandwith > > because you cant contol which interface is activly being used. > > > > > > > > > > > Thanks! > > > Tony > > > > -----Original Message----- > > > > From: Satish Patel > > > > Sent: Sunday, November 8, 2020 6:51 PM > > > > To: Tony Liu > > > > Cc: Laurent Dumont ; OpenStack Discuss > > > > > > > > Subject: Re: openvswitch+dpdk 100% cpu usage of ovs-vswitchd > > > > > > > > Thank you tony, > > > > > > > > We are running openstack cloud with SR-IOV and we are happy with > > > > performance but one big issue, it doesn't support bonding on compute > > > > nodes, we can do bonding inside VM but that is over complicated to do > > > > that level of deployment, without bonding it's always risky if tor > > > > switch dies. that is why i started looking into DPDK but look like i hit > > > > the wall again because my compute node has only 2 NIC we i can't do > > > > bonding while i am connected over same nic. Anyway i will stick with SR- > > > > IOV in that case to get more performance and less complexity. > > > > > > > > On Sun, Nov 8, 2020 at 3:22 PM Tony Liu wrote: > > > > > > > > > > SRIOV gives you the maximum performance, without any SW features > > > > > (security group, L3 routing, etc.), because it bypasses SW. > > > > > DPDK gives you less performance, with all SW features. > > > > > > > > > > Depend on the use case, max perf and SW features, you will need to > > > > > make a decision. > > > > > > > > > > > > > > > Tony > > > > > > -----Original Message----- > > > > > > From: Laurent Dumont > > > > > > Sent: Sunday, November 8, 2020 9:04 AM > > > > > > To: Satish Patel > > > > > > Cc: OpenStack Discuss > > > > > > Subject: Re: openvswitch+dpdk 100% cpu usage of ovs-vswitchd > > > > > > > > > > > > I have limited hands-on experience with both but they don't serve > > > > > > the same purpose/have the same implementation. You use SRIOV to > > > > > > allow Tenants to access the NIC cards directly and bypass any > > > > > > inherent linux- vr/OVS performance limitations. This is key for NFV > > > > > > workloads which are expecting large amount of PPS + low latency > > > > > > (because they are often just virtualized bare-metal products with > > > > > > one real cloud- readiness/architecture ;) ) - This means that a > > > > > > Tenant with an SRIOV port can use DPDK + access the NIC through the > > > > > > VF which means (in theory) a better performance than OVS+DPDK. > > > > > > > > > > > > You use ovs-dpdk to increase the performance of OVS based flows (so > > > > > > provider networks + vxlan based internal-tenant networks). > > > > > > > > > > > > On Sun, Nov 8, 2020 at 11:13 AM Satish Patel > > > > > > wrote: > > > > > > > > > > > > > > > > > >        Thanks. Just curious then why people directly go for SR-IOV > > > > > >       implementation where they get better performance + they can > > > > use the > > > > > >       same CPU more also. What are the measure advantages or > > > > features > > > > > >       attracting the community to go with DPDK over SR-IOV? > > > > > > > > > > > >       On Sun, Nov 8, 2020 at 10:50 AM Laurent Dumont > > > > > > > wrote: > > > > > >       > > > > > > >       > As far as I know, DPDK enabled cores will show 100% usage at > > > > > > all times. > > > > > >       > > > > > > >       > On Sun, Nov 8, 2020 at 9:39 AM Satish Patel > > > > > > > wrote: > > > > > >       >> > > > > > >       >> Folks, > > > > > >       >> > > > > > >       >> Recently i have added come compute nodes in cloud > > > > supporting > > > > > >       >> openvswitch-dpdk for performance. I am seeing all my PMD > > > > > > cpu cores are > > > > > >       >> 100% cpu usage on linux top command. It is normal behavior > > > > > > from first > > > > > >       >> looks. It's very scary to see 400% cpu usage on top. Can > > > > someone > > > > > >       >> confirm before I assume it's normal and what we can do to > > > > > > reduce it if > > > > > >       >> it's too high? > > > > > >       >> > > > > > > > > > > > > > > > > From satish.txt at gmail.com Mon Nov 9 15:11:19 2020 From: satish.txt at gmail.com (Satish Patel) Date: Mon, 9 Nov 2020 10:11:19 -0500 Subject: openvswitch+dpdk 100% cpu usage of ovs-vswitchd In-Reply-To: <80aaf9917fb3624b15af3f2119b65c115409d7f1.camel@redhat.com> References: <5d30d8f4a6cc6ea92c004f685d1e4501700cae80.camel@redhat.com> <80aaf9917fb3624b15af3f2119b65c115409d7f1.camel@redhat.com> Message-ID: That would be great, thank you. Let me try to create VF based bonding inside DPDK and see how it goes. On Mon, Nov 9, 2020 at 9:30 AM Sean Mooney wrote: > > On Mon, 2020-11-09 at 09:13 -0500, Satish Patel wrote: > > Thank Sean, > > > > I have Intel NIC > > > > [root at infra-lxb-1 ~]# lspci | grep -i eth > > 06:00.0 Ethernet controller: Intel Corporation 82599 10 Gigabit Dual > > Port Backplane Connection (rev 01) > > 06:00.1 Ethernet controller: Intel Corporation 82599 10 Gigabit Dual > > Port Backplane Connection (rev 01) > > > > I was thinking if i can create a couple VF out of SR-IOV interface and > > on a computer machine i create two bonding interfaces. bond-1 for mgmt > > and bond-2 for OVS+DPDK then it will solve my all problem related TOR > > switches redundancy. > > > > I don't think we can add VF as an interface in OVS for DPDK. > you can and if you create the bond on the host first it basically defeets teh reason for using dpdk > the kernel bond driver will be a bottelneck for dpdk. if you want to bond dpdk interfaces then you should > create that bond in ovs by adding the two vfs and then creatign an ovs bond. > > > On Mon, Nov 9, 2020 at 9:03 AM Sean Mooney wrote: > > > > > > On Mon, 2020-11-09 at 04:41 +0000, Tony Liu wrote: > > > > Bonding is a SW feature supported by either kernel or DPDK layer. > > > > In case of SRIOV, it's not complicated to enable bonding inside VM. > > > > And it has to be two NICs connecting to two ToRs. > > > > > > > > Depending on DPDK implementation, you might be able to use VF. > > > > Anyways, it's always recommended to have dedicated NIC for SRIOV. > > > for what its worth melonox do support bondign fo VF on the same card > > > i have never used it but bonding on the host is possibel for sriov. > > > im not sure if it works with openstack however but i belvie it does. > > > > > > you will have to reach out to mellonox to determin if it is. > > > most other nic vendors do not support bonding and it may limit other > > > feature like bandwith based schduling as really you can only list one of the interfaces bandwith > > > because you cant contol which interface is activly being used. > > > > > > > > > > > > > > > Thanks! > > > > Tony > > > > > -----Original Message----- > > > > > From: Satish Patel > > > > > Sent: Sunday, November 8, 2020 6:51 PM > > > > > To: Tony Liu > > > > > Cc: Laurent Dumont ; OpenStack Discuss > > > > > > > > > > Subject: Re: openvswitch+dpdk 100% cpu usage of ovs-vswitchd > > > > > > > > > > Thank you tony, > > > > > > > > > > We are running openstack cloud with SR-IOV and we are happy with > > > > > performance but one big issue, it doesn't support bonding on compute > > > > > nodes, we can do bonding inside VM but that is over complicated to do > > > > > that level of deployment, without bonding it's always risky if tor > > > > > switch dies. that is why i started looking into DPDK but look like i hit > > > > > the wall again because my compute node has only 2 NIC we i can't do > > > > > bonding while i am connected over same nic. Anyway i will stick with SR- > > > > > IOV in that case to get more performance and less complexity. > > > > > > > > > > On Sun, Nov 8, 2020 at 3:22 PM Tony Liu wrote: > > > > > > > > > > > > SRIOV gives you the maximum performance, without any SW features > > > > > > (security group, L3 routing, etc.), because it bypasses SW. > > > > > > DPDK gives you less performance, with all SW features. > > > > > > > > > > > > Depend on the use case, max perf and SW features, you will need to > > > > > > make a decision. > > > > > > > > > > > > > > > > > > Tony > > > > > > > -----Original Message----- > > > > > > > From: Laurent Dumont > > > > > > > Sent: Sunday, November 8, 2020 9:04 AM > > > > > > > To: Satish Patel > > > > > > > Cc: OpenStack Discuss > > > > > > > Subject: Re: openvswitch+dpdk 100% cpu usage of ovs-vswitchd > > > > > > > > > > > > > > I have limited hands-on experience with both but they don't serve > > > > > > > the same purpose/have the same implementation. You use SRIOV to > > > > > > > allow Tenants to access the NIC cards directly and bypass any > > > > > > > inherent linux- vr/OVS performance limitations. This is key for NFV > > > > > > > workloads which are expecting large amount of PPS + low latency > > > > > > > (because they are often just virtualized bare-metal products with > > > > > > > one real cloud- readiness/architecture ;) ) - This means that a > > > > > > > Tenant with an SRIOV port can use DPDK + access the NIC through the > > > > > > > VF which means (in theory) a better performance than OVS+DPDK. > > > > > > > > > > > > > > You use ovs-dpdk to increase the performance of OVS based flows (so > > > > > > > provider networks + vxlan based internal-tenant networks). > > > > > > > > > > > > > > On Sun, Nov 8, 2020 at 11:13 AM Satish Patel > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Thanks. Just curious then why people directly go for SR-IOV > > > > > > > implementation where they get better performance + they can > > > > > use the > > > > > > > same CPU more also. What are the measure advantages or > > > > > features > > > > > > > attracting the community to go with DPDK over SR-IOV? > > > > > > > > > > > > > > On Sun, Nov 8, 2020 at 10:50 AM Laurent Dumont > > > > > > > > wrote: > > > > > > > > > > > > > > > > As far as I know, DPDK enabled cores will show 100% usage at > > > > > > > all times. > > > > > > > > > > > > > > > > On Sun, Nov 8, 2020 at 9:39 AM Satish Patel > > > > > > > > wrote: > > > > > > > >> > > > > > > > >> Folks, > > > > > > > >> > > > > > > > >> Recently i have added come compute nodes in cloud > > > > > supporting > > > > > > > >> openvswitch-dpdk for performance. I am seeing all my PMD > > > > > > > cpu cores are > > > > > > > >> 100% cpu usage on linux top command. It is normal behavior > > > > > > > from first > > > > > > > >> looks. It's very scary to see 400% cpu usage on top. Can > > > > > someone > > > > > > > >> confirm before I assume it's normal and what we can do to > > > > > > > reduce it if > > > > > > > >> it's too high? > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > From arne.wiebalck at cern.ch Mon Nov 9 15:43:30 2020 From: arne.wiebalck at cern.ch (Arne Wiebalck) Date: Mon, 9 Nov 2020 16:43:30 +0100 Subject: [baremetal-sig][ironic] Tue Nov 10, 2pm UTC: Baremetal and ML2 networking Message-ID: <2a4befd4-ebb1-4589-572a-8a1da6f4f325@cern.ch> Dear all, The Bare Metal SIG will meet tomorrow, Tue Nov 10 at 2pm UTC, with a "topic-of-the-day"(*) presentation by Julia on Bare Metal + ML2 Networking: Why it is this way (feat. 3d printer calibration cubes!) All details for this meeting and upcoming topics can be found on the SIG's etherpad: https://etherpad.opendev.org/p/bare-metal-sig Everyone is welcome, don't miss out! Cheers, Arne (*) The Bare Metal SIG has at each meeting a ~10 minute introduction to or presentation of a bare metal related topic. From juliaashleykreger at gmail.com Mon Nov 9 16:14:59 2020 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Mon, 9 Nov 2020 08:14:59 -0800 Subject: [oslo][release] Oslo's Transition To Independent In-Reply-To: References: <4a9dc3ba-ef77-fdfd-2729-b7cb6357e3ed@nemebean.com> Message-ID: Top posting because I'm a horrible person. Anyway, I think moving oslo to independent makes lots of sense, at least to me. The key I think is to have the ability to backport and release a patch/revisin/fix release if there is a major issue, but the obligation to backport or even set a foundation to do so is a whole other matter. My overall feeling, for something as stable as the oslo libraries, that cycle-with-intermediacy path may just end up being a frustrating headache, that is if the team feels confident and actively manages their own releases of the various libraries. Also, Under the existing model and policy of the release team, they would basically end up back where they started if the libraries failed to release multiple times, which may not make sense for stable libraries. Anyway, just my $0.02. -Julia On Fri, Nov 6, 2020 at 2:04 AM Herve Beraud wrote: > > First, thanks for your answer. > > Le mer. 4 nov. 2020 à 15:50, Ben Nemec a écrit : >> >> >> >> On 11/4/20 7:31 AM, Herve Beraud wrote: >> > Greetings, >> > >> > Is it time for us to move some parts of Oslo to the independent release >> > model [1]? >> > >> > I think we could consider Oslo world is mostly stable enough to answer >> > yes to the previous question. >> > >> > However, the goal of this email is to trigger the debat and see which >> > deliverables could be transitioned to the independent model. >> > >> > Do we need to expect that major changes will happen within Oslo and who >> > could warrant to continue to follow cycle-with-intermediary model [2]? >> >> I would hesitate to try to predict the future on what will see major >> changes and what won't. I would prefer to look at this more from the >> perspective of what Oslo libraries are tied to the OpenStack version. >> For example, I don't think oslo.messaging should be moved to >> independent. It's important that RPC has a sane version to version >> upgrade path, and the easiest way to ensure that is to keep it on the >> regular cycle release schedule. The same goes for other libraries too: >> oslo.versionedobjects, oslo.policy, oslo.service, oslo.db, possibly also >> things like oslo.config and oslo.context (I suspect contexts need to be >> release-specific, but maybe someone from a consuming project can weigh >> in). Even oslo.serialization could have upgrade impacts if it is being >> used to serialize internal data in a service. > > > Agreed, the goal here isn't to try to move everything to the independent model but more to identify which projects could be eligible for this switch. > I strongly agree that the previous list of projects that you quote should stay binded to openstack cycles and should continue to rely on stable branches. > These kinds of projects and also openstack's services are strongly tied to backends, their version, and available APIs and so to openstack's series, so they must remain linked to them. > >> >> That said, many of the others can probably be moved. oslo.i18n and >> oslo.upgradecheck are both pretty stable at this point and not really >> tied to a specific release. As long as we're responsible with any future >> changes to them it should be pretty safe to make them independent. > > > Agreed. > >> >> This does raise a question though: Are the benefits of going independent >> with the release model sufficient to justify splitting the release >> models of the Oslo projects? I assume the motivation is to avoid having >> to do as many backports of bug fixes, but if we're mostly doing this >> with low-volume, stable projects does it gain us that much? > > > Yes, you're right, it could help us to reduce our needed maintenance and so our Oslo's activity in general. > Indeed, about 35 projects are hosted by Oslo and concerning the active maintainers the trend isn't on the rise. > So reducing the number of stable branches to maintain could benefit us, and it could be done by moving projects to an independent model. > >> >> >> I guess I don't have a strong opinion one way or another on this yet, >> and would defer to our release liaisons if they want to go one way or >> other other. Hopefully this provides some things to think about though. > > > Yes you provided interesting observations, thanks. > It could be interesting to get feedback from other cores. > >> >> -Ben >> > > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > From gouthampravi at gmail.com Mon Nov 9 16:39:10 2020 From: gouthampravi at gmail.com (Goutham Pacha Ravi) Date: Mon, 9 Nov 2020 08:39:10 -0800 Subject: Which deployment method for ceph (rook|ceph-ansible|tripleo) In-Reply-To: <3BF6161C-B8D5-46E1-ACA3-3516BE901D1F@me.com> References: <20201103151029.dyixpfoput5rgyae@barron.net> <3BF6161C-B8D5-46E1-ACA3-3516BE901D1F@me.com> Message-ID: On Tue, Nov 3, 2020 at 12:11 PM Oliver Weinmann wrote: > Hi Tom, > > Thanks a lot for your input. Highly appreciated. John really convinced me > to deploy a > Standalone cluster with cephadm and so I started to deploy It. I stumbled > upon a few obstacles, but mostly because commands didn’t behave as expected > or myself missing some important steps like adding 3 dashes in a yml file. > Cephadm looks really promising. I hope that by tomorrow I will have a > simple 3 node cluster. I have to look deeper into it as of how to configure > separate networks for the cluster and the Frontend but it shouldn’t be too > hard. Once the cluster is functioning I will re-deploy my tripleo POC > pointing to the standalone Ceph cluster. Currently I have a zfs nfs Storage > configured that I would like to keep. I have to figure out how to configure > multiple backends in tripleo. > Is the ZFS NFS storage going to be managed by the ZFSOnLinux driver in Manila? Or is this Oracle ZFSSA? Configuring integrated backends [2] in TripleO is fairly straightforward - but neither of the drivers above are integrated into TripleO, you'll have to use *ExtraConfig steps to shove the config into manila.conf: https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/node_config.html Something along these lines: http://paste.openstack.org/show/799832/ > > Cheers, > Oliver > > Von meinem iPhone gesendet > > > Am 03.11.2020 um 16:20 schrieb Tom Barron : > > > > On 01/11/20 08:55 +0100, Oliver Weinmann wrote: > >> Hi, > >> > >> I'm still in the process of preparing a OpenStack POC. I'm 100% sure > that I want to use CEPH and so I purchased the book Mastering CEPH 2nd > edition. First of all, It's a really good book. It basically explains the > various methods how ceph can be deployed and also the components that CEPH > is build of. So I played around a lot with ceph-ansible and rook in my > virtualbox environment. I also started to play with tripleo ceph > deployment, although I haven't had the time yet to sucessfully deploy a > openstack cluster with CEPH. Now I'm wondering, which of these 3 methods > should I use? > >> > >> rook > >> > >> ceph-ansible > >> > >> tripleo > >> > >> I also want to use CEPH for NFS and CIFS (Samba) as we have plenty of > VMs running under vSphere that currently consume storage from a ZFS storage > via CIFS and NFS. I don't know if rook can be used for this. I have the > feeling that it is purely meant to be used for kubernetes? And If I would > like to have CIFS and NFS maybe tripleo is not capable of enabling these > features in CEPH? So I would be left with ceph-ansible? > >> > >> Any suggestions are very welcome. > >> > >> Best Regards, > >> > >> Oliver > >> > >> > > > > If your core use case is OpenStack (OpenStack POC with CEPH) then of the > three tools mentioned only tripleo will deploy OpenStack. It can deploy a > Ceph cluster for use by OpenStack as well, or you can deploy Ceph > externally and it will "point" to it from OpenStack. For an OpenStack POC > (and maybe for production too) I'd just have TripleO deploy the Ceph > cluster as well. TripleO will use a Ceph deployment tool -- today, > ceph-ansible; in the future, cephadm -- to do the actual Ceph cluster > deployment but it figures out how to run the Ceph deployment for you. > > > > I don't think any of these tools will install a Samba/CIFs gateway to > CephFS. It's reportedly on the road map for the new cephadm tool. You may > be able to manually retrofit it to your Ceph cluster by consulting upstream > guidance such as [1]. > > > > NFS shares provisioned in OpenStack (Manila file service) *could* be > shared out-of-cloud to VSphere VMs if networking is set up to make them > accessible but the shares would remain OpenStack managed. To use the same > Ceph cluster for OpenStack and vSphere but have separate storage pools > behind them, and independent management, you'd need to deploy the Ceph > cluster independently of OpenStack and vSphere. TripleO could "point" to > this cluster as mentioned previously. > > > > I agree with your assessment that rook is intended to provide PVs for > Kubernetes consumers. You didn't mention Kubernetes as a use case, but as > John Fulton has mentioned it is possible to use rook on Kubernetes in a > mode where it "points" to an external ceph cluster rather than provisioning > its own as well. Or if you run k8s clusters on OpenStack, they can just > consume the OpenStack storage, which will be Ceph storage when that is used > to back OpenStack Cinder and Manila. > > > > -- Tom Barron > > > > [1] > https://www.youtube.com/watch?v=5v8L7FhIyOw&list=PLrBUGiINAakNCnQUosh63LpHbf84vegNu&index=19&t=0s&app=desktop > > > > [2] https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/environments -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnsomor at gmail.com Mon Nov 9 16:40:39 2020 From: johnsomor at gmail.com (Michael Johnson) Date: Mon, 9 Nov 2020 08:40:39 -0800 Subject: [octavia] Timeouts during building of lb? But then successful In-Reply-To: <6266636F-EB91-4CAC-B5CA-228710483B67@datalounges.com> References: <6266636F-EB91-4CAC-B5CA-228710483B67@datalounges.com> Message-ID: Hi Florian, That is very unusual. It typically takes less than 30 seconds for a load balancer to be provisioned. It definitely sounds like the mysql instance is having trouble. This can also cause longer term issues if the query response time drops to 10 seconds or more(0.001 is normal), which could trigger unnecessary failovers. In Octavia there are layers of "retries" to attempt to handle clouds that are having trouble. It sounds like database issues are triggering one or more of these retries. There are a few retries that will be in play for database transactions: MySQL internal retries/timeouts such as lock timeouts (logged on the mysql side) oslo.db includes some automatic retries (typically not logged without configuration file settings) Octavia tenacity and flow retries (Typically logged if the configuration file has Debug = True enabled) This may also be a general network connection issue. The default REST timeouts (used when we connect to the amphora agents) is 600, I'm wondering if the lb-mgmt-network is also having an issue. Please check your health manager log files. If there are database query time issues logged, it would point specifically to a mysql issue. In the past we have seen mysql clustering setups that were bad and caused performance issues (flipping primary instance, lock contention between the instances, etc.). You should not be seeing any log messages that the mysql database went away, that is not normal. Michael On Sun, Nov 8, 2020 at 7:06 AM Florian Rommel wrote: > > Hi, so we have a fully functioning setup of octavia on ussuri and it works nicely, when it competes. > So here is what happens: > From octavia api to octavia worker takes 20 seconds for the job to be initiated. > The loadbalancer gets built quickly and then we get a mysql went away error, the listener gets built and then a member , that works too, then the mysql error comes up with query took too long to execute. > Now this is where it gets weird. This is all within the first 2 - 3 minutes. > At this point it hangs and takes 10 minutes (600 seconds) for the next step to complete and then another 10 minutes and another 10 until it’s completed. > It seems there is a timeout somewhere but even with debug on we do not see what is going on. Does anyone have a mysql 8 running and octavia executing fine? And could send me their redacted octavia or mysql conf files? We didn’t touch them but it seems that there is something off.. > especially since it then completes and works extremely nicely. > I would highly appreciate it , even off list. > Best regards, > //f > > From Akshay.346 at hsc.com Mon Nov 9 09:06:04 2020 From: Akshay.346 at hsc.com (Akshay 346) Date: Mon, 9 Nov 2020 09:06:04 +0000 Subject: Unable to build centos 8.2 qcow2 Message-ID: Hello All, I need to build centos 8.2 image using disk-image-builder. But by setting DIB_RELEASE with 8, it by default uses centos8.1 as base cloud image. How can I use centos 8.2 image? Also I tried setting DIB_CLOUD_IMAGES having my local path to centos 8.2 qcow2 but it appends centos8.1 name at the defined path. i.e /path/to/my/dir/centos8.2/CentOS-8-GenericCloud-8.1.1911-20200113.3.x86_64.qcow2 Please suggest how may I build centos 8.2 qcow2. Be safe Akshay DISCLAIMER: This electronic message and all of its contents, contains information which is privileged, confidential or otherwise protected from disclosure. The information contained in this electronic mail transmission is intended for use only by the individual or entity to which it is addressed. If you are not the intended recipient or may have received this electronic mail transmission in error, please notify the sender immediately and delete / destroy all copies of this electronic mail transmission without disclosing, copying, distributing, forwarding, printing or retaining any part of it. Hughes Systique accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cboylan at sapwetik.org Mon Nov 9 21:38:16 2020 From: cboylan at sapwetik.org (Clark Boylan) Date: Mon, 09 Nov 2020 13:38:16 -0800 Subject: Unable to build centos 8.2 qcow2 In-Reply-To: References: Message-ID: <468e57d7-b3b5-4eff-8f96-76f2df1e83bb@www.fastmail.com> On Mon, Nov 9, 2020, at 1:06 AM, Akshay 346 wrote: > > Hello All, > > > > I need to build centos 8.2 image using disk-image-builder. > > But by setting DIB_RELEASE with 8, it by default uses centos8.1 as base > cloud image. How can I use centos 8.2 image? > > > > Also I tried setting DIB_CLOUD_IMAGES having my local path to centos > 8.2 qcow2 but it appends centos8.1 name at the defined path. > > i.e > /path/to/my/dir/centos8.2/CentOS-8-GenericCloud-8.1.1911-20200113.3.x86_64.qcow2 > > > > Please suggest how may I build centos 8.2 qcow2. Looking at the dib code [0] that does the image selection the other variables at play are $DIB_FLAVOR and $ARCH. If I set DIB_RELEASE=8, DIB_FLAVOR=GenericCloud, and ARCH=x86_64 then running `curl -s https://cloud.centos.org/centos/${DIB_RELEASE}/${ARCH}/images/ | grep -o "CentOS-.[^>]*${DIB_FLAVOR}-.[^>]*.qcow2" | sort -r | head -1` produces "CentOS-8-GenericCloud-8.2.2004-20200611.2.x86_64.qcow2". I suspect that means if I were to run a build it would be based on that image. Can you double check you aren't setting DIB_FLAVOR to another value that may not support 8.2 yet or perhaps another ARCH? Also, if you can share logs from the build via a paste service that would be helpful in debugging. One other thing to consider is that you can use the centos-minimal element instead which will build an image from scratch using yum/dnf. > > > > Be safe > > Akshay [0] https://opendev.org/openstack/diskimage-builder/src/branch/master/diskimage_builder/elements/centos/root.d/10-centos-cloud-image#L50-L56 From florian at datalounges.com Tue Nov 10 08:30:00 2020 From: florian at datalounges.com (Florian Rommel) Date: Tue, 10 Nov 2020 10:30:00 +0200 Subject: [octavia] Timeouts during building of lb? But then successful In-Reply-To: References: <6266636F-EB91-4CAC-B5CA-228710483B67@datalounges.com> Message-ID: <4F54784D-2107-4A23-9EFA-C262B69D0365@datalounges.com> Hi Micheal and thank you.. So it really seems that the mysql server ( fairly vanilla, non-clustered) is a problem.. I followed the installation instructions from the official documentation and yes, when I create a LB this is what comes through in the octavia-worker log: 2020-11-10 08:23:18.450 777550 INFO octavia.controller.queue.v1.endpoints [-] Creating member 'a6389dc7-61cb-489c-b69b-a922f0a9d9f2'... 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines [-] Database connection was found disconnected; reconnecting: oslo_db.exception.DBConnectionError: (pymysql.err.OperationalError) (2013, 'Lost connection to MySQL server during query’) The server right now runs on localhost (mysql) I changed that to see if the problem persists.. There is no iptables currently running to prevent rate limited etc. We made almost no modifications to the my.cnf and octavia is the only one that has problems.. all other services have no issues at all. Is there some specific settings I should set in the octavia.conf that deal with this? Here is the python trace, which in my opnion is fairly basic… (Background on this error at: http://sqlalche.me/e/e3q8) 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines Traceback (most recent call last): 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1245, in _execute_context 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines self.dialect.do_execute( 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 581, in do_execute 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines cursor.execute(statement, parameters) 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/pymysql/cursors.py", line 170, in execute 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines result = self._query(query) 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/pymysql/cursors.py", line 328, in _query 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines conn.query(q) 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/pymysql/connections.py", line 517, in query 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines self._affected_rows = self._read_query_result(unbuffered=unbuffered) 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/pymysql/connections.py", line 732, in _read_query_result 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines result.read() 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/pymysql/connections.py", line 1075, in read 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines first_packet = self.connection._read_packet() 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/pymysql/connections.py", line 657, in _read_packet 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines packet_header = self._read_bytes(4) 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/pymysql/connections.py", line 706, in _read_bytes 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines raise err.OperationalError( 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines pymysql.err.OperationalError: (2013, 'Lost connection to MySQL server during query') 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines The above exception was the direct cause of the following exception: 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines Traceback (most recent call last): 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/oslo_db/sqlalchemy/engines.py", line 73, in _connect_ping_listener 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines connection.scalar(select([1])) 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 914, in scalar 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines return self.execute(object_, *multiparams, **params).scalar() 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 982, in execute 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines return meth(self, multiparams, params) 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/sqlalchemy/sql/elements.py", line 287, in _execute_on_connection 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines return connection._execute_clauseelement(self, multiparams, params) 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1095, in _execute_clauseelement 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines ret = self._execute_context( 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1249, in _execute_context 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines self._handle_dbapi_exception( 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1474, in _handle_dbapi_exception 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines util.raise_from_cause(newraise, exc_info) 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 398, in raise_from_cause 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines reraise(type(exception), exception, tb=exc_tb, cause=cause) 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 152, in reraise 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines raise value.with_traceback(tb) 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1245, in _execute_context 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines self.dialect.do_execute( 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 581, in do_execute 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines cursor.execute(statement, parameters) 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/pymysql/cursors.py", line 170, in execute 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines result = self._query(query) 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/pymysql/cursors.py", line 328, in _query 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines conn.query(q) 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/pymysql/connections.py", line 517, in query 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines self._affected_rows = self._read_query_result(unbuffered=unbuffered) 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/pymysql/connections.py", line 732, in _read_query_result 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines result.read() 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/pymysql/connections.py", line 1075, in read 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines first_packet = self.connection._read_packet() 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/pymysql/connections.py", line 657, in _read_packet 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines packet_header = self._read_bytes(4) 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines File "/usr/lib/python3/dist-packages/pymysql/connections.py", line 706, in _read_bytes 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines raise err.OperationalError( 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines oslo_db.exception.DBConnectionError: (pymysql.err.OperationalError) (2013, 'Lost connection to MySQL server during query') 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines [SQL: SELECT 1] 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines (Background on this error at: http://sqlalche.me/e/e3q8) 2020-11-10 08:23:18.458 777550 ERROR oslo_db.sqlalchemy.engines The other option is to run it all verbos? Best regards //F > On 9. Nov 2020, at 18.40, Michael Johnson wrote: > > Hi Florian, > > That is very unusual. It typically takes less than 30 seconds for a > load balancer to be provisioned. It definitely sounds like the mysql > instance is having trouble. This can also cause longer term issues if > the query response time drops to 10 seconds or more(0.001 is normal), > which could trigger unnecessary failovers. > > In Octavia there are layers of "retries" to attempt to handle clouds > that are having trouble. It sounds like database issues are triggering > one or more of these retries. > There are a few retries that will be in play for database transactions: > MySQL internal retries/timeouts such as lock timeouts (logged on the mysql side) > oslo.db includes some automatic retries (typically not logged without > configuration file settings) > Octavia tenacity and flow retries (Typically logged if the > configuration file has Debug = True enabled) > > This may also be a general network connection issue. The default REST > timeouts (used when we connect to the amphora agents) is 600, I'm > wondering if the lb-mgmt-network is also having an issue. > > Please check your health manager log files. If there are database > query time issues logged, it would point specifically to a mysql > issue. In the past we have seen mysql clustering setups that were bad > and caused performance issues (flipping primary instance, lock > contention between the instances, etc.). You should not be seeing any > log messages that the mysql database went away, that is not normal. > > Michael > > On Sun, Nov 8, 2020 at 7:06 AM Florian Rommel wrote: >> >> Hi, so we have a fully functioning setup of octavia on ussuri and it works nicely, when it competes. >> So here is what happens: >> From octavia api to octavia worker takes 20 seconds for the job to be initiated. >> The loadbalancer gets built quickly and then we get a mysql went away error, the listener gets built and then a member , that works too, then the mysql error comes up with query took too long to execute. >> Now this is where it gets weird. This is all within the first 2 - 3 minutes. >> At this point it hangs and takes 10 minutes (600 seconds) for the next step to complete and then another 10 minutes and another 10 until it’s completed. >> It seems there is a timeout somewhere but even with debug on we do not see what is going on. Does anyone have a mysql 8 running and octavia executing fine? And could send me their redacted octavia or mysql conf files? We didn’t touch them but it seems that there is something off.. >> especially since it then completes and works extremely nicely. >> I would highly appreciate it , even off list. >> Best regards, >> //f >> >> > From doug at stackhpc.com Tue Nov 10 09:02:58 2020 From: doug at stackhpc.com (Doug) Date: Tue, 10 Nov 2020 09:02:58 +0000 Subject: [kolla] Proposing wu.chunyang for Kolla core In-Reply-To: References: Message-ID: <3246e30d-a77f-d697-2a73-bca70060f30c@stackhpc.com> On 09/11/2020 11:33, Mark Goddard wrote: > Hi, > > I would like to propose adding wu.chunyang to the kolla-core and > kolla-ansible-core groups. wu.chunyang did some great work on Octavia > integration in the Victoria release, and has provided some helpful > reviews. > > Cores - please reply +1/-1 before the end of Friday 13th November. +1, thanks for your efforts! > > Thanks, > Mark > From hberaud at redhat.com Tue Nov 10 09:24:45 2020 From: hberaud at redhat.com (Herve Beraud) Date: Tue, 10 Nov 2020 10:24:45 +0100 Subject: [oslo] New courtesy ping list for Wallaby Message-ID: Hello, As we discussed during our previous meeting, I'll be clearing the current ping list in the next few weeks. This is to prevent courtesy pinging people who are no longer active on the project. If you wish to continue receiving courtesy pings at the start of the Oslo meeting please add yourself to the new list on the agenda template [1]. Note that the new list is above the template, called "Courtesy ping for Wallaby". If you add yourself again to the end of the existing list I'll assume you want to be left on though. Thanks. Hervé [1] https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_Template -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtantsur at redhat.com Tue Nov 10 10:15:24 2020 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Tue, 10 Nov 2020 11:15:24 +0100 Subject: [ironic] SPUC times! Message-ID: Hi folks, I nearly forgot about SPUC, can you imagine? :) Anyway, after staring at the doodle for some time (it wasn't easy!), I've picked two time slots: Friday, 10am UTC (in https://bluejeans.com/643711802) Friday, 5pm UTC (in https://bluejeans.com/313987753) Apologies for those who cannot make them! We're starting this Friday (the 13th!). I'm taking a day off, so I won't necessarily be present, but feel free to use the meeting IDs without me as well. SPUC will run till X-mas (maybe we should even have an X-mas special on the 25th?). Cheers, Dmitry -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill -------------- next part -------------- An HTML attachment was scrubbed... URL: From berendt at betacloud-solutions.de Tue Nov 10 11:26:10 2020 From: berendt at betacloud-solutions.de (Christian Berendt) Date: Tue, 10 Nov 2020 12:26:10 +0100 Subject: [kolla] Proposing wu.chunyang for Kolla core In-Reply-To: References: Message-ID: <8F0D5876-7991-4691-9545-0B1BEBF2BC36@betacloud-solutions.de> > Am 09.11.2020 um 12:33 schrieb Mark Goddard : > > Cores - please reply +1/-1 before the end of Friday 13th November. +1 From geguileo at redhat.com Tue Nov 10 12:06:06 2020 From: geguileo at redhat.com (Gorka Eguileor) Date: Tue, 10 Nov 2020 13:06:06 +0100 Subject: multiple nfs shares with cinder-backup In-Reply-To: References: Message-ID: <20201110120606.ky2t2gerwouolwqn@localhost> On 04/11, MaSch wrote: > Hello all! > > I'm currently using openstack queens with cinder 12.0.10. > I would like to a backend I'm using a NFS-share. > > Now i would like to spit my backups up to two nfs-shares. > I have seen that the cinder.volume.driver can handle multiple nfs shares. > But it seems that cinder.backup.driver can not. > > Is there a way to use two nfs shares for backups? > Or is it maybe possible with a later release of Cinder? > > regards, > MaSch > > Hi, Currently the cinder-backup service has two deployment options: tightly coupled, and non-coupled. The non-coupled version is the usual way to deploy it, as you can run it in Active-Active mode, and it only supports a single backend. The coupled deployment allows you to have multiple backends, one backend per cinder-backup service and host, but each backup backend can only backup volumes from the cinder-volume service deployed on the same host. Cheers, Gorka. From radoslaw.piliszek at gmail.com Tue Nov 10 12:55:12 2020 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Tue, 10 Nov 2020 13:55:12 +0100 Subject: multiple nfs shares with cinder-backup In-Reply-To: References: Message-ID: On Wed, Nov 4, 2020 at 11:45 AM MaSch wrote: > > Hello all! > > I'm currently using openstack queens with cinder 12.0.10. > I would like to a backend I'm using a NFS-share. > > Now i would like to spit my backups up to two nfs-shares. > I have seen that the cinder.volume.driver can handle multiple nfs shares. > But it seems that cinder.backup.driver can not. > > Is there a way to use two nfs shares for backups? > Or is it maybe possible with a later release of Cinder? > > regards, > MaSch > > You can use directories where you mount different NFS shares. Cinder Backup allows you to specify the directory to use for backup so this way you can segregate the backups. Just specify --container in your commands. -yoctozepto From vhariria at redhat.com Tue Nov 10 14:42:08 2020 From: vhariria at redhat.com (Vida Haririan) Date: Tue, 10 Nov 2020 09:42:08 -0500 Subject: [Manila] Bug Squash upcoming event on 19th Nov 2020 Message-ID: Hi everyone, Back by popular demand :) We are planning the next Bug Squash session focusing on bugs that require API/DB changes as identified in Victoria Cycle. The event will be held all day on 19th Nov 2020, with a synchronous bug triage call at 15:00 UTC using this Jitsi bridge [1]. A list of bugs targeted for the Wallaby Cycle are available for review [2]. Please Feel free to flag an existing bug on the list or add any bugs that you plan on addressing early in the Cycle. Your participation is much appreciated, and we look forward to you joining us for this event. Thanks in advance, Vida [1] https://meetpad.opendev.org/ManilaW-ReleaseBugSquash [2] https://ethercalc.openstack.org/birpr9a6bd0b -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralonsoh at redhat.com Tue Nov 10 14:50:32 2020 From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez) Date: Tue, 10 Nov 2020 15:50:32 +0100 Subject: [neutron] Bug deputy week 45 (2020/10/02 - 2020/10/08) Message-ID: Hello: This is the weekly summary of Neutron bugs reported: Critical: - https://bugs.launchpad.net/neutron/+bug/1902678 [Fullstack] Wrong output of the cmdline causes tests timeouts Patch: https://review.opendev.org/#/c/761202/ - https://bugs.launchpad.net/neutron/+bug/1902843 [rocky]Rally job is broken in the Neutron stable/rocky branch *Not assigned* - https://bugs.launchpad.net/neutron/+bug/1902844 Error while removing subnet after test *Not assigned* High: - https://bugs.launchpad.net/neutron/+bug/1902775 neutron-rally-task fails on stable/rocky: SyntaxError: invalid syntax Patch: https://review.opendev.org/#/c/761391/ (merged) - https://bugs.launchpad.net/neutron/+bug/1902917 Anti-spoofing bypass using Open vSwitch *Not assigned* - https://bugs.launchpad.net/neutron/+bug/1903696 Security group OVO object don't reloads and make compatible rules objects Medium: - https://bugs.launchpad.net/neutron/+bug/1902888 [OVN] neutron db sync does not sync external_ids for routes Patch: https://review.opendev.org/#/c/761420/ - https://bugs.launchpad.net/neutron/+bug/1902950 [OVN] DNS resolution not forwarded with OVN driver *Not assigned* - https://bugs.launchpad.net/neutron/+bug/1902998 tempest test_create_router_set_gateway_with_fixed_ip often fails with DVR Patch: https://review.opendev.org/#/c/761498/ - https://bugs.launchpad.net/neutron/+bug/1903433 The duplicate route in l3 router namespace results in North-South traffic breaking Patch: https://review.opendev.org/#/c/761829/ - https://bugs.launchpad.net/neutron/+bug/1903689 [stable/ussuri] Functional job fails - AttributeError: module 'neutron_lib.constants' has no attribute 'DEVICE_OWNER_DISTRIBUTED' *Not assigned* Low: - https://bugs.launchpad.net/neutron/+bug/1903008 Create network failed during functional test *Not assigned* Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juliaashleykreger at gmail.com Tue Nov 10 15:44:16 2020 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Tue, 10 Nov 2020 07:44:16 -0800 Subject: [ironic] SPUC times! In-Reply-To: References: Message-ID: On Tue, Nov 10, 2020 at 2:23 AM Dmitry Tantsur wrote: > > Hi folks, > > I nearly forgot about SPUC, can you imagine? :) > > Anyway, after staring at the doodle for some time (it wasn't easy!), I've picked two time slots: > Friday, 10am UTC (in https://bluejeans.com/643711802) > Friday, 5pm UTC (in https://bluejeans.com/313987753) > > Apologies for those who cannot make them! > > We're starting this Friday (the 13th!). I'm taking a day off, so I won't necessarily be present, but feel free to use the meeting IDs without me as well. SPUC will run till X-mas (maybe we should even have an X-mas special on the 25th?). I _really_ like this idea. Ultimately we are a huge giant family, and there is no reason we cannot bond on what is a special day for some. > > Cheers, > Dmitry > > -- > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill From ildiko.vancsa at gmail.com Tue Nov 10 16:46:45 2020 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Tue, 10 Nov 2020 17:46:45 +0100 Subject: [edge] Open Geospatial Consortium presentation on the next Edge WG call Message-ID: <25BF983B-A24A-4F66-8F52-E106DFA9FBA4@gmail.com> Hi, I’m reaching out to draw your attention to an upcoming presentation on the Edge Computing Group weekly call next Monday. We will have a presentation from the Open Geospatial Consortium where you can learn about their use cases relevant to edge computing and more specifically about the importance of location in that context. In the remaining time on the call we will discuss some of the requirements of the use cases such as location-awareness of infrastructure services and look into collaboration opportunities. The call is on __Monday (November 16) at 1400 UTC__. If you are interested in joining the call and the discussions you can find the dial-in information here: https://wiki.openstack.org/wiki/Edge_Computing_Group#Next_meeting:_Monday_.28November_16.29.2C_6am_PST_.2F_1400_UTC Please let me know if you have any questions. Thanks, Ildikó From tamm.maari at gmail.com Tue Nov 10 17:19:23 2020 From: tamm.maari at gmail.com (Maari Tamm) Date: Tue, 10 Nov 2020 19:19:23 +0200 Subject: [manila][OSC] Priorities for implementing the OSC share commands Message-ID: <6EB02241-97BE-42D3-837F-5206956059B9@gmail.com> Hi Everyone! Slowly but steady we are implementing the OpenStack Client for Manila. For the upcoming release we are aiming to implement the following commands, in no particular order: Share Replicas: openstack share replica create / delete / list / show / set / promote / resync Share Replica Export Locations: openstack share replica export location list / show Share Manage/Unmanage: openstack share adopt / abandon Services: openstack share service set / list Share Pools: openstack share pool list User Messages: openstack share message delete / list / show Availability Zones (add support for manila): openstack availability zone list Limits (add support for manila): openstack limits show —absolute /—rate Share Export Locations (ready for reviews: https://review.opendev.org/#/c/761661/ ): openstack share export location list / show Share Snapshots patch II (ready for reviews: https://review.opendev.org/#/c/746458/ ) : openstack share snapshot adopt / abandon openstack share snapshot export location show / list openstack share snapshot access create / delete / list To make this happen we could really use help reviewing the patches, once proposed. As linked above, two patches are currently ready for testing/reviews. We’d also very much appreciate getting some feedback on the list itself. Are we missing something important that would be useful for operators and should be implemented this cycle? If anyone has some commands in mind, please do let us know! Mohammed Naser and Belmiro Moreira, would love to get your thoughts on this as well! :) Thanks, Maari Tamm (IRC: maaritamm) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkopec at redhat.com Tue Nov 10 18:28:00 2020 From: mkopec at redhat.com (Martin Kopec) Date: Tue, 10 Nov 2020 19:28:00 +0100 Subject: [openstack][qa][tempest] tempest cleanup ansible role Message-ID: Hello all, we have implemented a tempest-cleanup ansible role [1] which runs the 'tempest cleanup' tool [2]. The role might be beneficial for you in case you run tempest tests multiple times within the same environment and you wanna make sure no leftover resources are present after the first run. The other great use case is to verify that your tempest tests are not leaving any resources behind after the tests are completed. 'tempest cleanup' can take care of the services defined here [3] - a service which doesn't have a class definition there cannot be discovered by the tool. If the resource you would wanna have cleaned is not in [3] help us please improve the tool and tell us about it or add it there yourself. [1] https://opendev.org/openstack/tempest/src/branch/master/roles/tempest-cleanup [2] https://docs.openstack.org/tempest/latest/cleanup.html [3] https://opendev.org/openstack/tempest/src/branch/master/tempest/cmd/cleanup_service.py Regards, -- Martin Kopec Quality Engineer Red Hat EMEA -------------- next part -------------- An HTML attachment was scrubbed... URL: From hello at dincercelik.com Tue Nov 10 18:43:20 2020 From: hello at dincercelik.com (Dincer Celik) Date: Tue, 10 Nov 2020 21:43:20 +0300 Subject: [kolla] Proposing wu.chunyang for Kolla core In-Reply-To: References: Message-ID: <626B9F93-BC2A-4D6B-A43A-99BAC93842B0@dincercelik.com> +1 > On 9 Nov 2020, at 14:33, Mark Goddard wrote: > > Hi, > > I would like to propose adding wu.chunyang to the kolla-core and > kolla-ansible-core groups. wu.chunyang did some great work on Octavia > integration in the Victoria release, and has provided some helpful > reviews. > > Cores - please reply +1/-1 before the end of Friday 13th November. > > Thanks, > Mark > From lbragstad at gmail.com Tue Nov 10 18:50:13 2020 From: lbragstad at gmail.com (Lance Bragstad) Date: Tue, 10 Nov 2020 12:50:13 -0600 Subject: [qa][policy] Testing strategy discussion for new RBAC (new scope and default role combinations) In-Reply-To: <1758f922fe5.b2f4514a220341.5965440098876721164@ghanshyammann.com> References: <1758f922fe5.b2f4514a220341.5965440098876721164@ghanshyammann.com> Message-ID: Hey folks, We held the meeting today and we started capturing some notes in an etherpad [0]. Most of today's discussion was focused on introducing context. We didn't come to a definitive answer as to which testing strategy is best. We're going to have another meeting on Monday, November 16th (next Monday) at 16:00 UTC. We're also going to use the same conferencing room Ghanshyam sent out in the initial email [1]. Feel free to add thoughts to the etherpad [0] before hand. [0] https://etherpad.opendev.org/p/wallaby-secure-rbac-testing [1] https://bluejeans.com/749897818 On Tue, Nov 3, 2020 at 1:25 PM Ghanshyam Mann wrote: > Hello Everyone, > > To continue the discussion on how projects should test the new RBAC (scope > as well as the new defaults combination), > we will host a call on bluejeans on Tuesday 10th Nov 16.00 UTC. > > Lance has set up the room for that: https://bluejeans.com/749897818 > > Feel free to join if you are interested in that or would like to help with > this effort. > > -gmann > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Tue Nov 10 19:15:55 2020 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 10 Nov 2020 13:15:55 -0600 Subject: [tc][all][searchlight ] Retiring the Searchlight project Message-ID: <175b3960913.120cf390316504.5945799248975474230@ghanshyammann.com> Hello Everyone, As you know, Searchlight is a leaderless project for the Wallaby cycle, which means there is no PTL candidate to lead it in the Wallaby cycle. 'No PTL' and no liaisons for DPL model is one of the criteria which triggers TC to start checking the health, maintainers of the project for dropping the project from OpenStack Governance[1]. TC discussed the leaderless project in PTG[2] and checked if the project has maintainers and what activities are done in the Victoria development cycle. It seems no functional changes in Searchlight repos except few gate fixes or community goal commits[3]. Based on all these checks and no maintainer for Searchlight, TC decided to drop this project from OpenStack governance in the Wallaby cycle. Ref: Mandatory Repository Retirement resolution [4] and the detailed process is in the project guide docs [5]. If your organization product/customer use/rely on this project then this is the right time to step forward to maintain it otherwise from the Wallaby cycle, Searchlight will move out of OpenStack governance by keeping their repo under OpenStack namespace with an empty master branch with 'Not Maintained' message in README. If someone from old or new maintainers shows interest to continue its development then it can be re-added to OpenStack governance. With that thanks to Searchlight contributors and PTLs for maintaining this project. [1] https://governance.openstack.org/tc/reference/dropping-projects.html [2] https://etherpad.opendev.org/p/tc-wallaby-ptg [3] https://www.stackalytics.com/?release=victoria&module=searchlight-group&metric=commits [4] https://governance.openstack.org/tc/resolutions/20190711-mandatory-repository-retirement.html [5] https://docs.openstack.org/project-team-guide/repository.html#retiring-a-repository -gmann From gmann at ghanshyammann.com Tue Nov 10 19:16:08 2020 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 10 Nov 2020 13:16:08 -0600 Subject: [tc][all][qinling] Retiring the Qinling project Message-ID: <175b3963a49.115662abe16508.6386586116324619581@ghanshyammann.com> Hello Everyone, As you know, Qinling is a leaderless project for the Wallaby cycle, which means there is no PTL candidate to lead it in the Wallaby cycle. 'No PTL' and no liaisons for DPL model is one of the criteria which triggers TC to start checking the health, maintainers of the project for dropping the project from OpenStack Governance[1]. TC discussed the leaderless project in PTG[2] and checked if the project has maintainers and what activities are done in the Victoria development cycle. It seems no functional changes in Qinling repos except few gate fixes or community goal commits[3]. Based on all these checks and no maintainer for Qinling, TC decided to drop this project from OpenStack governance in the Wallaby cycle. Ref: Mandatory Repository Retirement resolution [4] and the detailed process is in the project guide docs [5]. If your organization product/customer use/rely on this project then this is the right time to step forward to maintain it otherwise from the Wallaby cycle, Qinling will move out of OpenStack governance by keeping their repo under OpenStack namespace with an empty master branch with 'Not Maintained' message in README. If someone from old or new maintainers shows interest to continue its development then it can be re-added to OpenStack governance. With that thanks to Qinling contributors and PTLs (especially lxkong ) for maintaining this project. [1] https://governance.openstack.org/tc/reference/dropping-projects.html [2] https://etherpad.opendev.org/p/tc-wallaby-ptg [3] https://www.stackalytics.com/?release=victoria&module=qinling-group&metric=commits [4] https://governance.openstack.org/tc/resolutions/20190711-mandatory-repository-retirement.html [5] https://docs.openstack.org/project-team-guide/repository.html#retiring-a-repository -gmann From henry at thebonaths.com Tue Nov 10 20:23:50 2020 From: henry at thebonaths.com (Henry Bonath) Date: Tue, 10 Nov 2020 15:23:50 -0500 Subject: CloudKitty deployment on Train and/or Ussuri In-Reply-To: References: Message-ID: Hi Jocelyn, I am also an Openstack-Ansible user, who is in the same market of trying to find Rating-as-A-Service for my Train cloud. I stumbled upon your message here after running into the same exact issue that you are having and searching for answers, and am glad to hear that I am not alone. (Don't you hate when you only find more questions??) I am testing Cloudkitty v13.0.0 right now and running into the same issue as you are as it relates to 'cloudkitty-api'. I also found that the templated config you referenced needs to be updated as well. I'm going to continue to soldier through this and try to get a working configuration, were you able to make any progress on the issue with cloudkitty-api? Please let me know if we can work together to get this working, I can submit any patches to the openstack-ansible-os_cloudkitty repo. -Henry On Fri, Oct 23, 2020 at 2:38 AM Thode Jocelyn wrote: > > Hi, > > > > I was looking at the possibilities to have Rating-as-A-Service in our Openstack (currently train but planning to move to Ussuri) and I stumbled upon CloudKitty. I’m currently facing multiple issues with cloudkitty itself and with openstack-ansible. (We are using a containerized deployment with LXC) > > > > I noticed that openstack-ansible has no playbook yet to install a service like CloudKitty even though starting from Ussuri it was added in the ansible-role-requirements.yml. I have created a small patch to be able to install CloudKitty via openstack-ansible and if this is of interest I could potentially submit a PR with this. > The os_cloudkitty role seems to kinda work and only with a relatively old version of CloudKitty. For example, here : https://opendev.org/openstack/openstack-ansible-os_cloudkitty/src/branch/stable/train/templates/cloudkitty.conf.j2#L38 since CloudKitty v8.0.0 the section should be named “[fetcher_keystone]”, but I found no information as to which CloudKitty version should be used with this role. Does someone have any recommendation as to which version should be used and if there is any interest in improving the role to support more recent versions of CloudKitty? > Even when tweaking the configuration and installing v7.0.0 of Cloudkitty it only fixes cloudkitty-processor, I was never able to make cloudkitty-api work I always get an error like “Fatal Python error: Py_Initialize: Unable to get the locale encoding ModuleNotFoundError: No module named 'encodings'”. Any input on this would be greatly appreciated. > > > > > Cheers > > Jocelyn From zigo at debian.org Tue Nov 10 21:12:33 2020 From: zigo at debian.org (Thomas Goirand) Date: Tue, 10 Nov 2020 22:12:33 +0100 Subject: [tc][all][searchlight ] Retiring the Searchlight project In-Reply-To: <175b3960913.120cf390316504.5945799248975474230@ghanshyammann.com> References: <175b3960913.120cf390316504.5945799248975474230@ghanshyammann.com> Message-ID: <297cf22b-2172-cb51-f282-4c0e674a9a07@debian.org> On 11/10/20 8:15 PM, Ghanshyam Mann wrote: > Hello Everyone, > > As you know, Searchlight is a leaderless project for the Wallaby cycle, which means there is no PTL > candidate to lead it in the Wallaby cycle. 'No PTL' and no liaisons for DPL model is one of the criteria > which triggers TC to start checking the health, maintainers of the project for dropping the project > from OpenStack Governance[1]. > > TC discussed the leaderless project in PTG[2] and checked if the project has maintainers and > what activities are done in the Victoria development cycle. It seems no functional changes in Searchlight > repos except few gate fixes or community goal commits[3]. > > Based on all these checks and no maintainer for Searchlight, TC decided to drop this project from OpenStack > governance in the Wallaby cycle. Ref: Mandatory Repository Retirement resolution [4] and the detailed process > is in the project guide docs [5]. > > If your organization product/customer use/rely on this project then this is the right time to step forward to > maintain it otherwise from the Wallaby cycle, Searchlight will move out of OpenStack governance by keeping their > repo under OpenStack namespace with an empty master branch with 'Not Maintained' message in README. > If someone from old or new maintainers shows interest to continue its development then it can be re-added > to OpenStack governance. > > With that thanks to Searchlight contributors and PTLs for maintaining this project. > > [1] https://governance.openstack.org/tc/reference/dropping-projects.html > [2] https://etherpad.opendev.org/p/tc-wallaby-ptg > [3] https://www.stackalytics.com/?release=victoria&module=searchlight-group&metric=commits > [4] https://governance.openstack.org/tc/resolutions/20190711-mandatory-repository-retirement.html > [5] https://docs.openstack.org/project-team-guide/repository.html#retiring-a-repository > > -gmann Hi, When some projects are being removed, does this mean that there's going to be a community effort to remove the dependency on the clients? IMO, it really should be done. I'm thinking about: - congressclient - qinlinclient - searchlightclient - karborclient All of the above only reached Debian because they were dependencies of other projects... Cheers, Thomas Goirand From kennelson11 at gmail.com Tue Nov 10 21:18:13 2020 From: kennelson11 at gmail.com (Kendall Nelson) Date: Tue, 10 Nov 2020 13:18:13 -0800 Subject: [tc][all][karbor] Retiring the Qinling project Message-ID: Hello Everyone, As you know, Karbor is a leaderless project for the Wallaby cycle, which means there is no PTL candidate to lead it in the Wallaby cycle. 'No PTL' and no liaisons for DPL model is one of the criteria which triggers TC to start checking the health, maintainers of the project for dropping the project from OpenStack Governance[1]. TC discussed the leaderless project in PTG[2] and checked if the project has maintainers and what activities are done in the Victoria development cycle. It seems no functional changes in Karbor repos except few gate fixes or community goal commits[3]. Based on all these checks and no maintainer for Karbor, TC decided to drop this project from OpenStack governance in the Wallaby cycle. Ref: Mandatory Repository Retirement resolution [4] and the detailed process is in the project guide docs [5]. If your organization product/customer use/rely on this project then this is the right time to step forward to maintain it otherwise from the Wallaby cycle, Karbor will move out of OpenStack governance by keeping their repo under OpenStack namespace with an empty master branch with 'Not Maintained' message in README. If someone from old or new maintainers shows interest to continue its development then it can be re-added to OpenStack governance. With that thanks to Karbor contributors and PTLs (especially Pengju Jiao) for maintaining this project. -Kendall Nelson (diablo_rojo) [1] https://governance.openstack.org/tc/reference/dropping-projects.html [2] https://etherpad.opendev.org/p/tc-wallaby-ptg [3] https://www.stackalytics.com/?release=victoria&module=karbor-group&metric=commits [4] https://governance.openstack.org/tc/resolutions/20190711-mandatory-repository-retirement.html [5] https://docs.openstack.org/project-team-guide/repository.html#retiring-a-repository -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennelson11 at gmail.com Tue Nov 10 21:20:31 2020 From: kennelson11 at gmail.com (Kendall Nelson) Date: Tue, 10 Nov 2020 13:20:31 -0800 Subject: [tc][all][karbor] Retiring the Qinling project In-Reply-To: References: Message-ID: There's always something I miss... sorry. The subject line should say Karbor, nor Qinling. Starting a new thread. Please disregard this one. -Kendall (diablo_rojo) On Tue, Nov 10, 2020 at 1:18 PM Kendall Nelson wrote: > Hello Everyone, > > As you know, Karbor is a leaderless project for the Wallaby cycle, which means there is no PTL > candidate to lead it in the Wallaby cycle. 'No PTL' and no liaisons for DPL model is one of the criteria > which triggers TC to start checking the health, maintainers of the project for dropping the project > from OpenStack Governance[1]. > > TC discussed the leaderless project in PTG[2] and checked if the project has maintainers and what > activities are done in the Victoria development cycle. It seems no functional changes in Karbor repos > except few gate fixes or community goal commits[3]. > > Based on all these checks and no maintainer for Karbor, TC decided to drop this project from OpenStack > governance in the Wallaby cycle. Ref: Mandatory Repository Retirement resolution [4] and the detailed process > is in the project guide docs [5]. > > If your organization product/customer use/rely on this project then this is the right time to step forward to > maintain it otherwise from the Wallaby cycle, Karbor will move out of OpenStack governance by keeping > their repo under OpenStack namespace with an empty master branch with 'Not Maintained' message in README. > If someone from old or new maintainers shows interest to continue its development then it can be re-added > to OpenStack governance. > > With that thanks to Karbor contributors and PTLs (especially Pengju Jiao) for maintaining this project. > > -Kendall Nelson (diablo_rojo) > > [1] https://governance.openstack.org/tc/reference/dropping-projects.html > [2] https://etherpad.opendev.org/p/tc-wallaby-ptg > [3] https://www.stackalytics.com/?release=victoria&module=karbor-group&metric=commits > [4] https://governance.openstack.org/tc/resolutions/20190711-mandatory-repository-retirement.html > [5] https://docs.openstack.org/project-team-guide/repository.html#retiring-a-repository > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennelson11 at gmail.com Tue Nov 10 21:21:18 2020 From: kennelson11 at gmail.com (Kendall Nelson) Date: Tue, 10 Nov 2020 13:21:18 -0800 Subject: [tc][all][karbor] Retiring the Karbor project Message-ID: Hello Everyone, As you know, Karbor is a leaderless project for the Wallaby cycle, which means there is no PTL candidate to lead it in the Wallaby cycle. 'No PTL' and no liaisons for DPL model is one of the criteria which triggers TC to start checking the health, maintainers of the project for dropping the project from OpenStack Governance[1]. TC discussed the leaderless project in PTG[2] and checked if the project has maintainers and what activities are done in the Victoria development cycle. It seems no functional changes in Karbor repos except few gate fixes or community goal commits[3]. Based on all these checks and no maintainer for Karbor, TC decided to drop this project from OpenStack governance in the Wallaby cycle. Ref: Mandatory Repository Retirement resolution [4] and the detailed process is in the project guide docs [5]. If your organization product/customer use/rely on this project then this is the right time to step forward to maintain it otherwise from the Wallaby cycle, Karbor will move out of OpenStack governance by keeping their repo under OpenStack namespace with an empty master branch with 'Not Maintained' message in README. If someone from old or new maintainers shows interest to continue its development then it can be re-added to OpenStack governance. With that thanks to Karbor contributors and PTLs (especially Pengju Jiao) for maintaining this project. -Kendall Nelson (diablo_rojo) [1] https://governance.openstack.org/tc/reference/dropping-projects.html [2] https://etherpad.opendev.org/p/tc-wallaby-ptg [3] https://www.stackalytics.com/?release=victoria&module=karbor-group&metric=commits [4] https://governance.openstack.org/tc/resolutions/20190711-mandatory-repository-retirement.html [5] https://docs.openstack.org/project-team-guide/repository.html#retiring-a-repository -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Tue Nov 10 22:37:25 2020 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 10 Nov 2020 16:37:25 -0600 Subject: [tc][all][searchlight ] Retiring the Searchlight project In-Reply-To: <297cf22b-2172-cb51-f282-4c0e674a9a07@debian.org> References: <175b3960913.120cf390316504.5945799248975474230@ghanshyammann.com> <297cf22b-2172-cb51-f282-4c0e674a9a07@debian.org> Message-ID: <175b44e80fd.f4c0ee8420790.4317890968302424842@ghanshyammann.com> ---- On Tue, 10 Nov 2020 15:12:33 -0600 Thomas Goirand wrote ---- > On 11/10/20 8:15 PM, Ghanshyam Mann wrote: > > Hello Everyone, > > > > As you know, Searchlight is a leaderless project for the Wallaby cycle, which means there is no PTL > > candidate to lead it in the Wallaby cycle. 'No PTL' and no liaisons for DPL model is one of the criteria > > which triggers TC to start checking the health, maintainers of the project for dropping the project > > from OpenStack Governance[1]. > > > > TC discussed the leaderless project in PTG[2] and checked if the project has maintainers and > > what activities are done in the Victoria development cycle. It seems no functional changes in Searchlight > > repos except few gate fixes or community goal commits[3]. > > > > Based on all these checks and no maintainer for Searchlight, TC decided to drop this project from OpenStack > > governance in the Wallaby cycle. Ref: Mandatory Repository Retirement resolution [4] and the detailed process > > is in the project guide docs [5]. > > > > If your organization product/customer use/rely on this project then this is the right time to step forward to > > maintain it otherwise from the Wallaby cycle, Searchlight will move out of OpenStack governance by keeping their > > repo under OpenStack namespace with an empty master branch with 'Not Maintained' message in README. > > If someone from old or new maintainers shows interest to continue its development then it can be re-added > > to OpenStack governance. > > > > With that thanks to Searchlight contributors and PTLs for maintaining this project. > > > > [1] https://governance.openstack.org/tc/reference/dropping-projects.html > > [2] https://etherpad.opendev.org/p/tc-wallaby-ptg > > [3] https://www.stackalytics.com/?release=victoria&module=searchlight-group&metric=commits > > [4] https://governance.openstack.org/tc/resolutions/20190711-mandatory-repository-retirement.html > > [5] https://docs.openstack.org/project-team-guide/repository.html#retiring-a-repository > > > > -gmann > > Hi, > > When some projects are being removed, does this mean that there's going > to be a community effort to remove the dependency on the clients? IMO, > it really should be done. I'm thinking about: > Yes, as part of the retirement process all deliverables under the project needs to be removed and before removal we do: 1. Remove all dependencies. 2. Refactor/remove the gate job dependency also. 3. Remove the code from the retiring repo. > - congressclient This is already retired in Victoria cycle[1]. > - qinlinclient This client is also on the list of retirement in Wallaby so let's see if no maintainer then we will retire this too[2]. > - searchlightclient This is one of the deliverables under the Searchlight project so we will be retiring this repo alsp. > - karborclient Ditto[3]. [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014292.html [2] http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018638.html [3] http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018643.html -gmann > > All of the above only reached Debian because they were dependencies of > other projects... > > Cheers, > > Thomas Goirand > > From Arkady.Kanevsky at dell.com Tue Nov 10 22:59:20 2020 From: Arkady.Kanevsky at dell.com (Kanevsky, Arkady) Date: Tue, 10 Nov 2020 22:59:20 +0000 Subject: [tc][all][karbor] Retiring the Karbor project In-Reply-To: References: Message-ID: Let’s make sure we update https://www.openstack.org/software/ with the change. The same it true for all retiring projects. Thanks, Arkady From: Kendall Nelson Sent: Tuesday, November 10, 2020 3:21 PM To: OpenStack Discuss Subject: [tc][all][karbor] Retiring the Karbor project [EXTERNAL EMAIL] Hello Everyone, As you know, Karbor is a leaderless project for the Wallaby cycle, which means there is no PTL candidate to lead it in the Wallaby cycle. 'No PTL' and no liaisons for DPL model is one of the criteria which triggers TC to start checking the health, maintainers of the project for dropping the project from OpenStack Governance[1]. TC discussed the leaderless project in PTG[2] and checked if the project has maintainers and what activities are done in the Victoria development cycle. It seems no functional changes in Karbor repos except few gate fixes or community goal commits[3]. Based on all these checks and no maintainer for Karbor, TC decided to drop this project from OpenStack governance in the Wallaby cycle. Ref: Mandatory Repository Retirement resolution [4] and the detailed process is in the project guide docs [5]. If your organization product/customer use/rely on this project then this is the right time to step forward to maintain it otherwise from the Wallaby cycle, Karbor will move out of OpenStack governance by keeping their repo under OpenStack namespace with an empty master branch with 'Not Maintained' message in README. If someone from old or new maintainers shows interest to continue its development then it can be re-added to OpenStack governance. With that thanks to Karbor contributors and PTLs (especially Pengju Jiao) for maintaining this project. -Kendall Nelson (diablo_rojo) [1] https://governance.openstack.org/tc/reference/dropping-projects.html [2] https://etherpad.opendev.org/p/tc-wallaby-ptg [3] https://www.stackalytics.com/?release=victoria&module=karbor-group&metric=commits [4] https://governance.openstack.org/tc/resolutions/20190711-mandatory-repository-retirement.html [5] https://docs.openstack.org/project-team-guide/repository.html#retiring-a-repository -------------- next part -------------- An HTML attachment was scrubbed... URL: From helena at openstack.org Tue Nov 10 23:23:23 2020 From: helena at openstack.org (helena at openstack.org) Date: Tue, 10 Nov 2020 18:23:23 -0500 (EST) Subject: Victoria Release Community Meeting Message-ID: <1605050603.25113268@apps.rackspace.com> Hello, The community meeting for the Victoria release will be this Thursday, November 12th at 16:00 UTC. The meeting will be held via Zoom. We will show pre-recorded videos from our PTLs followed by live Q&A sessions. We will have updates from Masakari, Telemetry, Neutron, and Cinder. Zoom Info: [ https://zoom.us/j/2146866821?pwd=aDlpOXd5MXB3cExZWHlROEJURzh0QT09 ]( https://zoom.us/j/2146866821?pwd=aDlpOXd5MXB3cExZWHlROEJURzh0QT09 ) Meeting ID: 214 686 6821 Passcode: Victoria Find your local number: [ https://zoom.us/u/8BRrV ]( https://zoom.us/u/8BRrV ) Reminder to PTLs: We would love for you to participate and give an update on your project. I have attached a template for the slides that you may use if you wish. The video should be around 10 minutes. Please send in your video and slide for the community meeting ASAP. I have only received content for the listed above projects. If you are unable to make the meeting at the designated time we can show your video and forward any questions for you. Let me know if you have any other questions! Thank you for your participation, Helena -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwy5056 at gmail.com Wed Nov 11 03:21:09 2020 From: cwy5056 at gmail.com (fisheater chang) Date: Wed, 11 Nov 2020 13:21:09 +1000 Subject: [cinder][ceilometer][heat][instances] Installation Problems In-Reply-To: References: Message-ID: To whom it may concern, I am new to openstack, I got several errors when I installed the service followed by the installation guide. My openstack version : stein Ubuntu 18.0.4 1. Cinder-api is in /usr/bin/cinder-api, but when I type service cinder-api status, it shows Unit cinder-api.service could not be found. 2. Ceilometer and Heat tab didn't show in the Dashboard. 3. I was trying to launch an instance, but I got the status error and I tried to delete, but the instances can not be deleted. And I used nova force-delete instance-id, the error message is ERROR (ClientException): Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. (HTTP 500) (Request-ID: req-e6c0d966-c7ec-4f20-8e9f-c788018a8d81) I explored the openstack installation myself, just wondering if there is any online hands-on training or course that I can enroll in? Thanks. Kind regards, Walsh -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbasaras at gmail.com Wed Nov 11 07:30:40 2020 From: pbasaras at gmail.com (Pavlos Basaras) Date: Wed, 11 Nov 2020 09:30:40 +0200 Subject: Cannot deploly an instance at a specific host --(no such host found) [nova] Message-ID: Dear community, i am new to openstack. I have deployed devstack (on a virtual machine), and I can successfully deploy instances at the host where the controller is installed. I followed the instructions from https://docs.openstack.org/nova/queens/install/compute-install-ubuntu.html to add a new compute host, in order to be able to deploy VMs at the PC. Here is the output: openstack compute service list --service nova-compute +----+--------------+-----------+------+---------+-------+----------------------------+ | ID | Binary | Host | Zone | Status | State | Updated At | +----+--------------+-----------+------+---------+-------+----------------------------+ | 3 | nova-compute | openstack | nova | enabled | up | 2020-11-11T07:10:41.000000 | | 5 | nova-compute | computenode | nova | enabled | up | 2020-11-11T07:10:42.000000 | +----+--------------+-----------+------+---------+-------+----------------------------+ "computenode" is the new device that i added. When i try to deploy an instance from cli: openstack server create --flavor m1.tiny --image cirros034 --nic net-id=internal --security-group c8b06902-6664-4776-a8e9-0735ae251d34 --availability-zone nova:computenode mym--debug the reply i see from horizon is since there is an error in deploying the instance No valid host was found. No such host - host: computenode node: None any directions? all the best, Pavlos -------------- next part -------------- An HTML attachment was scrubbed... URL: From eblock at nde.ag Wed Nov 11 08:48:21 2020 From: eblock at nde.ag (Eugen Block) Date: Wed, 11 Nov 2020 08:48:21 +0000 Subject: Cannot deploly an instance at a specific host --(no such host found) [nova] In-Reply-To: Message-ID: <20201111084821.Horde.IJ-VF3rvTEHRsXedHGAq22g@webmail.nde.ag> Hi, is the compute node already discovered? Is the compute node visible in the output of: controller:~ # nova-manage cell_v2 list_hosts If not, you can run controller:~ # nova-manage cell_v2 discover_hosts and see if that helps. Regards, Eugen Zitat von Pavlos Basaras : > Dear community, > > i am new to openstack. > > I have deployed devstack (on a virtual machine), and I can > successfully deploy instances at the host where the controller is installed. > > I followed the instructions from > https://docs.openstack.org/nova/queens/install/compute-install-ubuntu.html > to add a new compute host, in order to be able to deploy VMs at the PC. > > Here is the output: > > openstack compute service list --service nova-compute > +----+--------------+-----------+------+---------+-------+----------------------------+ > | ID | Binary | Host | Zone | Status | State | Updated At > | > +----+--------------+-----------+------+---------+-------+----------------------------+ > | 3 | nova-compute | openstack | nova | enabled | up | > 2020-11-11T07:10:41.000000 | > | 5 | nova-compute | computenode | nova | enabled | up | > 2020-11-11T07:10:42.000000 | > +----+--------------+-----------+------+---------+-------+----------------------------+ > > "computenode" is the new device that i added. > > When i try to deploy an instance from cli: > openstack server create --flavor m1.tiny --image cirros034 --nic > net-id=internal --security-group c8b06902-6664-4776-a8e9-0735ae251d34 > --availability-zone nova:computenode mym--debug > > the reply i see from horizon is since there is an error in deploying the > instance > No valid host was found. No such host - host: computenode node: None > > any directions? > > all the best, > Pavlos From zhang.lei.fly+os-discuss at gmail.com Wed Nov 11 09:01:54 2020 From: zhang.lei.fly+os-discuss at gmail.com (Jeffrey Zhang) Date: Wed, 11 Nov 2020 17:01:54 +0800 Subject: [kolla] Proposing wu.chunyang for Kolla core In-Reply-To: <626B9F93-BC2A-4D6B-A43A-99BAC93842B0@dincercelik.com> References: <626B9F93-BC2A-4D6B-A43A-99BAC93842B0@dincercelik.com> Message-ID: +1 On Wed, Nov 11, 2020 at 2:46 AM Dincer Celik wrote: > +1 > > > On 9 Nov 2020, at 14:33, Mark Goddard wrote: > > > > Hi, > > > > I would like to propose adding wu.chunyang to the kolla-core and > > kolla-ansible-core groups. wu.chunyang did some great work on Octavia > > integration in the Victoria release, and has provided some helpful > > reviews. > > > > Cores - please reply +1/-1 before the end of Friday 13th November. > > > > Thanks, > > Mark > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zigo at debian.org Wed Nov 11 11:14:19 2020 From: zigo at debian.org (Thomas Goirand) Date: Wed, 11 Nov 2020 12:14:19 +0100 Subject: Victoria Release Community Meeting In-Reply-To: <1605050603.25113268@apps.rackspace.com> References: <1605050603.25113268@apps.rackspace.com> Message-ID: <4c09adb4-0f97-f256-9827-01781643a9c3@debian.org> On 11/11/20 12:23 AM, helena at openstack.org wrote: > The meeting will be held via Zoom. Could we *PLEASE* stop the Zoom non-sense? Zoom is: - known to have a poor security record - imposes the install of the desktop non-free app (yes I know, in some cases, it is supposed to work without it, but so far it didn't work for me) - controlled by a 3rd party we cannot trust It's not as if we had no alternatives. Jitsi works perfectly and was used successfully for the whole of debconf, with voctomix and stuff, so viewers can read a normal live video stream... If the foundation doesn't know how to do it, I can put people in touch with the Debian video team. I'm sure they will be helpful. Cheers, Thomas Goirand (zigo) From Aija.Jaunteva at dell.com Wed Nov 11 11:22:02 2020 From: Aija.Jaunteva at dell.com (Jaunteva, Aija) Date: Wed, 11 Nov 2020 11:22:02 +0000 Subject: [ironic] Configuration mold follow-up Message-ID: Hi, thank you for the responses to the poll. The meeting to discuss outstanding questions will be held on Thu, Nov 19, 2020 15:00 UTC. For details see [1]. Regards, Aija [1] https://etherpad.opendev.org/p/ironic-configuration-molds -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Wed Nov 11 12:24:25 2020 From: skaplons at redhat.com (Slawek Kaplonski) Date: Wed, 11 Nov 2020 13:24:25 +0100 Subject: Victoria Release Community Meeting In-Reply-To: <4c09adb4-0f97-f256-9827-01781643a9c3@debian.org> References: <1605050603.25113268@apps.rackspace.com> <4c09adb4-0f97-f256-9827-01781643a9c3@debian.org> Message-ID: <10079933.t8I2mb3pXR@p1> Hi, Dnia środa, 11 listopada 2020 12:14:19 CET Thomas Goirand pisze: > On 11/11/20 12:23 AM, helena at openstack.org wrote: > > The meeting will be held via Zoom. > > Could we *PLEASE* stop the Zoom non-sense? > > Zoom is: > - known to have a poor security record > - imposes the install of the desktop non-free app (yes I know, in some > cases, it is supposed to work without it, but so far it didn't work for me) > - controlled by a 3rd party we cannot trust > > It's not as if we had no alternatives. Jitsi works perfectly and was > used successfully for the whole of debconf, with voctomix and stuff, so > viewers can read a normal live video stream... > > If the foundation doesn't know how to do it, I can put people in touch > with the Debian video team. I'm sure they will be helpful. Actually foundation has Jitsii server also - see https://meetpad.opendev.org/ In Neutron team we were using it almost without problems during last PTG. But problem which we had with it was that it didn't work for people from China AFAIK so we had to switch to Zoom finally. Also I think that other teams had some scale issues with meetpad. But here I may be wrong and it could be problem on the PTG in June but not now, I don't really know for sure about it. > > Cheers, > > Thomas Goirand (zigo) -- Slawek Kaplonski Principal Software Engineer Red Hat From pbasaras at gmail.com Wed Nov 11 12:57:44 2020 From: pbasaras at gmail.com (Pavlos Basaras) Date: Wed, 11 Nov 2020 14:57:44 +0200 Subject: Cannot deploly an instance at a specific host --(no such host found) [nova] Message-ID: Hello, thanks very much for your prompt reply. regarding the first command "nova-manage cell_v2 list_hosts" the output is the following (openstack is the host of the controller). I dont see any other node here, even when i execute the discover_hosts command +-----------+--------------------------------------+-----------+ | Cell Name | Cell UUID | Hostname | +-----------+--------------------------------------+-----------+ | cell1 | 1522c22f-64d4-4882-8ae8-ed0f9407407c | openstack | +-----------+--------------------------------------+-----------+ Also this is the output from my controller when i use the command: sudo -s /bin/sh -c "nova-manage cell_v2 discover_hosts --verbose" nova (not sure if this helps) Found 2 cell mappings. Skipping cell0 since it does not contain hosts. Getting computes from cell 'cell1': 1522c22f-64d4-4882-8ae8-ed0f9407407c Found 0 unmapped computes in cell: 1522c22f-64d4-4882-8ae8-ed0f9407407c any thoughts? best, Pavlos. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eblock at nde.ag Wed Nov 11 13:20:22 2020 From: eblock at nde.ag (Eugen Block) Date: Wed, 11 Nov 2020 13:20:22 +0000 Subject: Cannot deploly an instance at a specific host --(no such host found) [nova] In-Reply-To: Message-ID: <20201111132022.Horde.q9K8xVfq2klzzypYBltanTa@webmail.nde.ag> Hm, indeed rather strange to me. Do you see anything in the nova-scheduler.log? If you activated the discover_hosts_in_cells_interval = 300 it should query for new hosts every 5 minutes. Zitat von Pavlos Basaras : > Hello, > > thanks very much for your prompt reply. > > > regarding the first command "nova-manage cell_v2 list_hosts" the output is > the following (openstack is the host of the controller). I dont see any > other node here, even when i execute the discover_hosts command > > +-----------+--------------------------------------+-----------+ > | Cell Name | Cell UUID | Hostname | > +-----------+--------------------------------------+-----------+ > | cell1 | 1522c22f-64d4-4882-8ae8-ed0f9407407c | openstack | > +-----------+--------------------------------------+-----------+ > > > Also this is the output from my controller when i use the command: sudo -s > /bin/sh -c "nova-manage cell_v2 discover_hosts --verbose" nova (not sure > if this helps) > Found 2 cell mappings. > Skipping cell0 since it does not contain hosts. > Getting computes from cell 'cell1': 1522c22f-64d4-4882-8ae8-ed0f9407407c > Found 0 unmapped computes in cell: 1522c22f-64d4-4882-8ae8-ed0f9407407c > > any thoughts? > > > best, > Pavlos. From pbasaras at gmail.com Wed Nov 11 13:37:14 2020 From: pbasaras at gmail.com (Pavlos Basaras) Date: Wed, 11 Nov 2020 15:37:14 +0200 Subject: Cannot deploly an instance at a specific host --(no such host found) [nova] In-Reply-To: <20201111132022.Horde.q9K8xVfq2klzzypYBltanTa@webmail.nde.ag> References: <20201111132022.Horde.q9K8xVfq2klzzypYBltanTa@webmail.nde.ag> Message-ID: Hello, yes i have this discover_hosts_in_cells_interval = 300 interestingly when i issued a combination of map_cell_and_hosts and update_cell the output from: nova-manage cell_v2 list_hosts +-----------+--------------------------------------+-------------+ | Cell Name | Cell UUID | Hostname | +-----------+--------------------------------------+-------------+ | None | 1a0fde85-8906-46fb-b721-01a28c978439 | computenode | | None | 1a0fde85-8906-46fb-b721-01a28c978439 | nrUE | | cell1 | 1522c22f-64d4-4882-8ae8-ed0f9407407c | openstack | +-----------+--------------------------------------+-------------+ when the new compute nodes seem to not have a cell mapped best, P. On Wed, Nov 11, 2020 at 3:26 PM Eugen Block wrote: > Hm, > > indeed rather strange to me. > > Do you see anything in the nova-scheduler.log? If you activated the > > discover_hosts_in_cells_interval = 300 > > it should query for new hosts every 5 minutes. > > > > Zitat von Pavlos Basaras : > > > Hello, > > > > thanks very much for your prompt reply. > > > > > > regarding the first command "nova-manage cell_v2 list_hosts" the output > is > > the following (openstack is the host of the controller). I dont see any > > other node here, even when i execute the discover_hosts command > > > > +-----------+--------------------------------------+-----------+ > > | Cell Name | Cell UUID | Hostname | > > +-----------+--------------------------------------+-----------+ > > | cell1 | 1522c22f-64d4-4882-8ae8-ed0f9407407c | openstack | > > +-----------+--------------------------------------+-----------+ > > > > > > Also this is the output from my controller when i use the command: sudo > -s > > /bin/sh -c "nova-manage cell_v2 discover_hosts --verbose" nova (not > sure > > if this helps) > > Found 2 cell mappings. > > Skipping cell0 since it does not contain hosts. > > Getting computes from cell 'cell1': 1522c22f-64d4-4882-8ae8-ed0f9407407c > > Found 0 unmapped computes in cell: 1522c22f-64d4-4882-8ae8-ed0f9407407c > > > > any thoughts? > > > > > > best, > > Pavlos. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eblock at nde.ag Wed Nov 11 14:03:28 2020 From: eblock at nde.ag (Eugen Block) Date: Wed, 11 Nov 2020 14:03:28 +0000 Subject: Cannot deploly an instance at a specific host --(no such host found) [nova] In-Reply-To: References: <20201111132022.Horde.q9K8xVfq2klzzypYBltanTa@webmail.nde.ag> Message-ID: <20201111140328.Horde.e4UaBmIP6Q_GOnn4VutjAea@webmail.nde.ag> There might be some mixup during the setup, I'm not sure how the other cell would be created. I'd probably delete the cell with UUID 1a0fde85-8906-46fb-b721-01a28c978439 and retry the discover_hosts with the right cell UUID: nova-manage cell_v2 delete_cell --cell_uuid 1a0fde85-8906-46fb-b721-01a28c978439 nova-manage cell_v2 discover_hosts --cell_uuid 1522c22f-64d4-4882-8ae8-ed0f9407407c Does that work? Zitat von Pavlos Basaras : > Hello, > > yes i have this discover_hosts_in_cells_interval = 300 > > > interestingly when i issued a combination of map_cell_and_hosts and > update_cell > > the output from: nova-manage cell_v2 list_hosts > +-----------+--------------------------------------+-------------+ > | Cell Name | Cell UUID | Hostname | > +-----------+--------------------------------------+-------------+ > | None | 1a0fde85-8906-46fb-b721-01a28c978439 | computenode | > | None | 1a0fde85-8906-46fb-b721-01a28c978439 | nrUE | > | cell1 | 1522c22f-64d4-4882-8ae8-ed0f9407407c | openstack | > +-----------+--------------------------------------+-------------+ > > when the new compute nodes seem to not have a cell mapped > > best, > P. > > > On Wed, Nov 11, 2020 at 3:26 PM Eugen Block wrote: > >> Hm, >> >> indeed rather strange to me. >> >> Do you see anything in the nova-scheduler.log? If you activated the >> >> discover_hosts_in_cells_interval = 300 >> >> it should query for new hosts every 5 minutes. >> >> >> >> Zitat von Pavlos Basaras : >> >> > Hello, >> > >> > thanks very much for your prompt reply. >> > >> > >> > regarding the first command "nova-manage cell_v2 list_hosts" the output >> is >> > the following (openstack is the host of the controller). I dont see any >> > other node here, even when i execute the discover_hosts command >> > >> > +-----------+--------------------------------------+-----------+ >> > | Cell Name | Cell UUID | Hostname | >> > +-----------+--------------------------------------+-----------+ >> > | cell1 | 1522c22f-64d4-4882-8ae8-ed0f9407407c | openstack | >> > +-----------+--------------------------------------+-----------+ >> > >> > >> > Also this is the output from my controller when i use the command: sudo >> -s >> > /bin/sh -c "nova-manage cell_v2 discover_hosts --verbose" nova (not >> sure >> > if this helps) >> > Found 2 cell mappings. >> > Skipping cell0 since it does not contain hosts. >> > Getting computes from cell 'cell1': 1522c22f-64d4-4882-8ae8-ed0f9407407c >> > Found 0 unmapped computes in cell: 1522c22f-64d4-4882-8ae8-ed0f9407407c >> > >> > any thoughts? >> > >> > >> > best, >> > Pavlos. >> >> >> >> >> From florian at datalounges.com Wed Nov 11 14:45:51 2020 From: florian at datalounges.com (florian at datalounges.com) Date: Wed, 11 Nov 2020 16:45:51 +0200 Subject: VS: [octavia] Timeouts during building of lb? But then successful In-Reply-To: References: <6266636F-EB91-4CAC-B5CA-228710483B67@datalounges.com> Message-ID: <006701d6b839$5da32d30$18e98790$@datalounges.com> Hi just as an update, because i think its rude to ask for help and not provide the solution, however stupid it may be. WE managed to get this working. So because we have a lot of worker threads through the openstack services, the connections ran out on Mysql 8 and obviously we increased the max_connections. This however ended up just closing the connections with no explanation , which was the original problem. It turns out that we used in the past open_files_limit : -1 , whichi n mysql 8 signifies 10000, however as described in some redhatt Bugzilla article, this seems to be not enough. As soon as we increased it to 65000 (our linux limit is much higher than that), everything went perfectly... Octavia now deploys within 1 minute. And even through hosted Kubernetes we deploy a LB via Octavia in under 3 minutes. Thank you Michael again for pointing me into the right direction //F -----Alkuperäinen viesti----- Lähettäjä: Michael Johnson Lähetetty: Monday, 9 November 2020 18.41 Vastaanottaja: Florian Rommel Kopio: openstack-discuss Aihe: Re: [octavia] Timeouts during building of lb? But then successful Hi Florian, That is very unusual. It typically takes less than 30 seconds for a load balancer to be provisioned. It definitely sounds like the mysql instance is having trouble. This can also cause longer term issues if the query response time drops to 10 seconds or more(0.001 is normal), which could trigger unnecessary failovers. In Octavia there are layers of "retries" to attempt to handle clouds that are having trouble. It sounds like database issues are triggering one or more of these retries. There are a few retries that will be in play for database transactions: MySQL internal retries/timeouts such as lock timeouts (logged on the mysql side) oslo.db includes some automatic retries (typically not logged without configuration file settings) Octavia tenacity and flow retries (Typically logged if the configuration file has Debug = True enabled) This may also be a general network connection issue. The default REST timeouts (used when we connect to the amphora agents) is 600, I'm wondering if the lb-mgmt-network is also having an issue. Please check your health manager log files. If there are database query time issues logged, it would point specifically to a mysql issue. In the past we have seen mysql clustering setups that were bad and caused performance issues (flipping primary instance, lock contention between the instances, etc.). You should not be seeing any log messages that the mysql database went away, that is not normal. Michael On Sun, Nov 8, 2020 at 7:06 AM Florian Rommel wrote: > > Hi, so we have a fully functioning setup of octavia on ussuri and it works nicely, when it competes. > So here is what happens: > From octavia api to octavia worker takes 20 seconds for the job to be initiated. > The loadbalancer gets built quickly and then we get a mysql went away error, the listener gets built and then a member , that works too, then the mysql error comes up with query took too long to execute. > Now this is where it gets weird. This is all within the first 2 - 3 minutes. > At this point it hangs and takes 10 minutes (600 seconds) for the next step to complete and then another 10 minutes and another 10 until it’s completed. > It seems there is a timeout somewhere but even with debug on we do not see what is going on. Does anyone have a mysql 8 running and octavia executing fine? And could send me their redacted octavia or mysql conf files? We didn’t touch them but it seems that there is something off.. > especially since it then completes and works extremely nicely. > I would highly appreciate it , even off list. > Best regards, > //f > > From fungi at yuggoth.org Wed Nov 11 14:46:18 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 11 Nov 2020 14:46:18 +0000 Subject: Victoria Release Community Meeting In-Reply-To: <10079933.t8I2mb3pXR@p1> References: <1605050603.25113268@apps.rackspace.com> <4c09adb4-0f97-f256-9827-01781643a9c3@debian.org> <10079933.t8I2mb3pXR@p1> Message-ID: <20201111144618.ndckzezqgbb2xble@yuggoth.org> On 2020-11-11 13:24:25 +0100 (+0100), Slawek Kaplonski wrote: [...] > Actually foundation has Jitsii server also - see > https://meetpad.opendev.org/ In Neutron team we were using it > almost without problems during last PTG. It's not really "the foundation" though, it's run by the OpenDev Collaboratory sysadmins and community. > But problem which we had with it was that it didn't work for > people from China AFAIK so we had to switch to Zoom finally. [...] This is unsubstantiated. We suspect people worldwide experience problems with getting WebRTC traffic through corporate firewalls, but on the whole people who live in mainland China have been conditioned to assume anything which doesn't work is being blocked by the government. We're working with some folks in China to attempt to prove or disprove it, but coordinating between timezones has slowed progress on that. We hope to have a better understanding of the local access problems for China, if any, soon. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From johnsomor at gmail.com Wed Nov 11 15:37:48 2020 From: johnsomor at gmail.com (Michael Johnson) Date: Wed, 11 Nov 2020 07:37:48 -0800 Subject: [octavia] Timeouts during building of lb? But then successful In-Reply-To: <006701d6b839$5da32d30$18e98790$@datalounges.com> References: <6266636F-EB91-4CAC-B5CA-228710483B67@datalounges.com> <006701d6b839$5da32d30$18e98790$@datalounges.com> Message-ID: Florian, I'm glad you are up and running. Thank you for providing the feedback on what was causing your issue, it will help us help others in the future. Michael On Wed, Nov 11, 2020 at 6:46 AM wrote: > > Hi just as an update, because i think its rude to ask for help and not provide the solution, however stupid it may be. > > WE managed to get this working. So because we have a lot of worker threads through the openstack services, the connections ran out on Mysql 8 and obviously we increased the max_connections. > > This however ended up just closing the connections with no explanation , which was the original problem. It turns out that we used in the past open_files_limit : -1 , whichi n mysql 8 signifies 10000, however as described in some redhatt Bugzilla article, this seems to be not enough. As soon as we increased it to 65000 (our linux limit is much higher than that), everything went perfectly... > > Octavia now deploys within 1 minute. And even through hosted Kubernetes we deploy a LB via Octavia in under 3 minutes. > > Thank you Michael again for pointing me into the right direction > //F > > -----Alkuperäinen viesti----- > Lähettäjä: Michael Johnson > Lähetetty: Monday, 9 November 2020 18.41 > Vastaanottaja: Florian Rommel > Kopio: openstack-discuss > Aihe: Re: [octavia] Timeouts during building of lb? But then successful > > Hi Florian, > > That is very unusual. It typically takes less than 30 seconds for a load balancer to be provisioned. It definitely sounds like the mysql instance is having trouble. This can also cause longer term issues if the query response time drops to 10 seconds or more(0.001 is normal), which could trigger unnecessary failovers. > > In Octavia there are layers of "retries" to attempt to handle clouds that are having trouble. It sounds like database issues are triggering one or more of these retries. > There are a few retries that will be in play for database transactions: > MySQL internal retries/timeouts such as lock timeouts (logged on the mysql side) oslo.db includes some automatic retries (typically not logged without configuration file settings) Octavia tenacity and flow retries (Typically logged if the configuration file has Debug = True enabled) > > This may also be a general network connection issue. The default REST timeouts (used when we connect to the amphora agents) is 600, I'm wondering if the lb-mgmt-network is also having an issue. > > Please check your health manager log files. If there are database query time issues logged, it would point specifically to a mysql issue. In the past we have seen mysql clustering setups that were bad and caused performance issues (flipping primary instance, lock contention between the instances, etc.). You should not be seeing any log messages that the mysql database went away, that is not normal. > > Michael > > On Sun, Nov 8, 2020 at 7:06 AM Florian Rommel wrote: > > > > Hi, so we have a fully functioning setup of octavia on ussuri and it works nicely, when it competes. > > So here is what happens: > > From octavia api to octavia worker takes 20 seconds for the job to be initiated. > > The loadbalancer gets built quickly and then we get a mysql went away error, the listener gets built and then a member , that works too, then the mysql error comes up with query took too long to execute. > > Now this is where it gets weird. This is all within the first 2 - 3 minutes. > > At this point it hangs and takes 10 minutes (600 seconds) for the next step to complete and then another 10 minutes and another 10 until it’s completed. > > It seems there is a timeout somewhere but even with debug on we do not see what is going on. Does anyone have a mysql 8 running and octavia executing fine? And could send me their redacted octavia or mysql conf files? We didn’t touch them but it seems that there is something off.. > > especially since it then completes and works extremely nicely. > > I would highly appreciate it , even off list. > > Best regards, > > //f > > > > > > > From eblock at nde.ag Wed Nov 11 15:41:17 2020 From: eblock at nde.ag (Eugen Block) Date: Wed, 11 Nov 2020 15:41:17 +0000 Subject: Question about the instance snapshot In-Reply-To: Message-ID: <20201111154117.Horde.rS6VTlLeua6yUDh3vuci3HY@webmail.nde.ag> Hi, taking an instance snapshot only applies to the root disk, other attached disks are not included. I don't have an explanation but I think it would be quite difficult to merge all contents from different disks into one image. If this is about backup and not creating new base images and your instances are volume-based you could create cinder snapshots of those volumes, for example by creating consistency-groups to have all volumes in a consistent state. If this is more about creating new base images rather than backups and you have an instance with its filesystem distributed across multiple volumes it would probably be better to either move everything to a single volume (easy when you're using LVM) or resize that instance with a larger disk size. There are several ways, it depends on your actual requirement. Regards, Eugen Zitat von Henry lol : > Hello, everyone > > I'm wondering whether the snapshot from the instance saves all disks > attached to the instance or only the main(=first) disk, because I can't > find any clear description for it. > > If the latter is true, should I detach all disks except for the main from > the instance before taking a snapshot, and why doesn't it support all > attached disks? > > Thanks > Sincerely, From oliver.weinmann at me.com Wed Nov 11 15:49:01 2020 From: oliver.weinmann at me.com (Oliver Weinmann) Date: Wed, 11 Nov 2020 15:49:01 -0000 Subject: =?utf-8?B?UmU6wqBDZW50T1MgOCBVc3N1cmkgY2FuJ3QgbGF1bmNoIGluc3RhbmNlIC91?= =?utf-8?B?c3IvbGliZXhlYy9xZW11LWt2bTogUGVybWlzc2lvbiBkZW5pZWQ=?= Message-ID: <07cd5a1b-1405-4e76-ae9d-fbce447ed8d3@me.com> Hi again, sorry to pick up this old post again but I manged to figure out what's wrong. The error: end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) only arises when using the nano flavor: openstack flavor create --id 0 --vcpus 1 --ram 64 --disk 1 m1.nano It works fine when using 128 instead of 64MB RAM: openstack flavor create --id 0 --vcpus 1 --ram 128 --disk 1 m1.nano Cheers, Oliver Am 19. Oktober 2020 um 16:21 schrieb Oliver Weinmann : Ok, I will try to disable selinux and deploy one more compute node. I just stumbled across another issue, not sure if it is related. The instance seems to be deployed just fine but now I looked on the console and neither cirros nor centos 7 seem to be booting up correctly. on cirros i see an error: [ 0.846019] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]--- and on centos7: error: not a correct XFS inode. I tried to create with ephemeral and volume. Cheers, Oliver Am 19. Oktober 2020 um 16:09 schrieb Alex Schultz : On Mon, Oct 19, 2020 at 7:59 AM Oliver Weinmann wrote: First of all thanks a lot for the quick reply. I just checked and it seems that the package is really not available for centos8 from the upstream repo: https://centos.pkgs.org/8/centos-appstream-x86_64/podman-1.6.4-15.module_el8.2.0+465+f9348e8f.x86_64.rpm.html When you say it should be available via rdo, does this mean I have to add or use a different repo when deploying undercloud / overcloud? I have followed the tripleo guide to deploy it: I thought we shipped it, maybe we don't because we run with selinux disabled so it doesn't show up in CI. https://docs.openstack.org/tripleo-docs/latest/ And is there a way to disable selinux on all overcloud nodes by default? I guess it is the default to disable it? Set the following in an environment file as part of the deployment: parameter_defaults: SELinuxMode: permissive Cheers, Oliver Am 19. Oktober 2020 um 15:29 schrieb Alex Schultz : On Mon, Oct 19, 2020 at 7:09 AM Oliver Weinmann wrote: Hi all, I have successfully deployed the overcloud many many times, but this time I have a strange behaviour. Whenever I try to launch an instance it fails. I checked the logs on the compute node and saw this error: Failed to build and run instance: libvirt.libvirtError: internal error: process exited while connecting to monitor: libvirt: error : cannot execute binary /usr/libexec/qemu-kvm: Permission denied googling led me to the solution to disable selinux: setenforce 0 I have not made this change persistent yet, as I would like to know why I'm facing this issue right now. What is actually the default for the overcloud nodes SeLinux? Enforcing, permissive or disabled? I build the ipa and overcloud image myself as I had to include drivers. Is this maybe the reason why SeLinux is now enabled, but is actually disabled when using the default ipa images? From a TripleO perspective, we do not officially support selinux enabled when running with CentOS. In theory it should work, however it is very dependent on versions. I think you're likely running into an issue with the correct version of podman which is likely causing this. We've had some issues as of late which require a very specific version of podman in order to work correctly with nova compute when running with selinux enabled. You need 1.6.4-15 or higher which I don't think is available with centos8. It should be available via RDO. Related: https://review.opendev.org/#/c/736173/ Thanks and Best Regards, Oliver -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at est.tech Wed Nov 11 16:35:56 2020 From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer) Date: Wed, 11 Nov 2020 17:35:56 +0100 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service Message-ID: Dear packagers and deployment engine developers, Since Icehouse nova-compute service does not need any database configuration as it uses the message bus to access data in the database via the conductor service. Also, the nova configuration guide states that the nova-compute service should not have the [api_database]connection config set. Having any DB credentials configured for the nova-compute is a security risk as well since that service runs close to the hypervisor. Since Rocky[1] nova-compute service fails if you configure API DB credentials and set upgrade_level config to 'auto'. Now we are proposing a patch[2] that makes nova-compute fail at startup if the [database]connection or the [api_database]connection is configured. We know that this breaks at least the rpm packaging, debian packaging, and puppet-nova. The problem there is that in an all-in-on deployment scenario the nova.conf file generated by these tools is shared between all the nova services and therefore nova-compute sees DB credentials. As a counter-example, devstack generates a separate nova-cpu.conf and passes that to the nova-compute service even in an all-in-on setup. The nova team would like to merge [2] during Wallaby but we are OK to delay the patch until Wallaby Milestone 2 so that the packagers and deployment tools can catch up. Please let us know if you are impacted and provide a way to track when you are ready with the modification that allows [2] to be merged. There was a long discussion on #openstack-nova today[3] around this topic. So you can find more detailed reasoning there[3]. Cheers, gibi [1] https://github.com/openstack/nova/blob/dc93e3b510f53d5b2198c8edd22528f0c899617e/nova/compute/rpcapi.py#L441-L457 [2] https://review.opendev.org/#/c/762176 [3] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2020-11-11.log.html#t2020-11-11T10:51:23 -- http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2020-11-11.log.html#t2020-11-11T14:40:51 From pbasaras at gmail.com Wed Nov 11 16:38:15 2020 From: pbasaras at gmail.com (Pavlos Basaras) Date: Wed, 11 Nov 2020 18:38:15 +0200 Subject: Cannot deploly an instance at a specific host --(no such host found) [nova] In-Reply-To: <20201111140328.Horde.e4UaBmIP6Q_GOnn4VutjAea@webmail.nde.ag> References: <20201111132022.Horde.q9K8xVfq2klzzypYBltanTa@webmail.nde.ag> <20201111140328.Horde.e4UaBmIP6Q_GOnn4VutjAea@webmail.nde.ag> Message-ID: Hello, maybe there is stg wrong with the installation. Let me clarify a few things. I have devstack deployed in a VM (pre-installed: keystone, glance, nova, placement, cinder, neutron, and horizon.) I can deploy machines successfully at the devstack controller space --everything seems to work fine. --> is seems to work fine with opensource mano as well I am trying to add another pc as a compute host to be able to deploy vms at this new compute host following ( https://docs.openstack.org/nova/queens/install/compute-install-ubuntu.html) Also attached the nova.conf file. The only major differences are: --the transport url for rabbitmq which i made according to the transport url of the controller, i.e., instead of rabbit://openstack:linux at controller i have rabbit://stackrabbit:linux at controller -- i replaced the ports with the service, e.g., instead using the 5000 port --> "http://controller/identity/v3" instead of "http://controller:5000/v3" please excuse (any) newbie questions all the best, Pavlos. On Wed, Nov 11, 2020 at 4:03 PM Eugen Block wrote: > There might be some mixup during the setup, I'm not sure how the other > cell would be created. I'd probably delete the cell with UUID > 1a0fde85-8906-46fb-b721-01a28c978439 and retry the discover_hosts with > the right cell UUID: > > nova-manage cell_v2 delete_cell --cell_uuid > 1a0fde85-8906-46fb-b721-01a28c978439 > nova-manage cell_v2 discover_hosts --cell_uuid > 1522c22f-64d4-4882-8ae8-ed0f9407407c > > Does that work? > > > Zitat von Pavlos Basaras : > > > Hello, > > > > yes i have this discover_hosts_in_cells_interval = 300 > > > > > > interestingly when i issued a combination of map_cell_and_hosts and > > update_cell > > > > the output from: nova-manage cell_v2 list_hosts > > +-----------+--------------------------------------+-------------+ > > | Cell Name | Cell UUID | Hostname | > > +-----------+--------------------------------------+-------------+ > > | None | 1a0fde85-8906-46fb-b721-01a28c978439 | computenode | > > | None | 1a0fde85-8906-46fb-b721-01a28c978439 | nrUE | > > | cell1 | 1522c22f-64d4-4882-8ae8-ed0f9407407c | openstack | > > +-----------+--------------------------------------+-------------+ > > > > when the new compute nodes seem to not have a cell mapped > > > > best, > > P. > > > > > > On Wed, Nov 11, 2020 at 3:26 PM Eugen Block wrote: > > > >> Hm, > >> > >> indeed rather strange to me. > >> > >> Do you see anything in the nova-scheduler.log? If you activated the > >> > >> discover_hosts_in_cells_interval = 300 > >> > >> it should query for new hosts every 5 minutes. > >> > >> > >> > >> Zitat von Pavlos Basaras : > >> > >> > Hello, > >> > > >> > thanks very much for your prompt reply. > >> > > >> > > >> > regarding the first command "nova-manage cell_v2 list_hosts" the > output > >> is > >> > the following (openstack is the host of the controller). I dont see > any > >> > other node here, even when i execute the discover_hosts command > >> > > >> > +-----------+--------------------------------------+-----------+ > >> > | Cell Name | Cell UUID | Hostname | > >> > +-----------+--------------------------------------+-----------+ > >> > | cell1 | 1522c22f-64d4-4882-8ae8-ed0f9407407c | openstack | > >> > +-----------+--------------------------------------+-----------+ > >> > > >> > > >> > Also this is the output from my controller when i use the command: > sudo > >> -s > >> > /bin/sh -c "nova-manage cell_v2 discover_hosts --verbose" nova (not > >> sure > >> > if this helps) > >> > Found 2 cell mappings. > >> > Skipping cell0 since it does not contain hosts. > >> > Getting computes from cell 'cell1': > 1522c22f-64d4-4882-8ae8-ed0f9407407c > >> > Found 0 unmapped computes in cell: > 1522c22f-64d4-4882-8ae8-ed0f9407407c > >> > > >> > any thoughts? > >> > > >> > > >> > best, > >> > Pavlos. > >> > >> > >> > >> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- [DEFAULT] #log_dir = /var/log/nova lock_path = /var/lock/nova state_path = /var/lib/nova #pavlos --start #transport_url = rabbit://admin:linux at 192.168.40.184 #transport_url = rabbit://openstack:linux at controller transport_url = rabbit://stackrabbit:linux at controller #transport_url = rabbit://admin:linux at 192.168.40.184:5672/ my_ip = 192.168.111.139 use_neutron = True firewall_driver = nova.virt.firewall.NoopFirewallDriver #pavlos --end # # From nova.conf # # # Availability zone for internal services. # # This option determines the availability zone for the various internal nova # services, such as 'nova-scheduler', 'nova-conductor', etc. # # Possible values: # # * Any string representing an existing availability zone name. # (string value) #internal_service_availability_zone = internal # # Default availability zone for compute services. # # This option determines the default availability zone for 'nova-compute' # services, which will be used if the service(s) do not belong to aggregates # with # availability zone metadata. # # Possible values: # # * Any string representing an existing availability zone name. # (string value) #default_availability_zone = nova # # Default availability zone for instances. # # This option determines the default availability zone for instances, which will # be used when a user does not specify one when creating an instance. The # instance(s) will be bound to this availability zone for their lifetime. # # Possible values: # # * Any string representing an existing availability zone name. # * None, which means that the instance can move from one availability zone to # another during its lifetime if it is moved from one compute node to another. # (string value) #default_schedule_zone = # Length of generated instance admin passwords. (integer value) # Minimum value: 0 #password_length = 12 # # Time period to generate instance usages for. It is possible to define optional # offset to given period by appending @ character followed by a number defining # offset. # # Possible values: # # * period, example: ``hour``, ``day``, ``month` or ``year`` # * period with offset, example: ``month at 15`` will result in monthly audits # starting on 15th day of month. # (string value) #instance_usage_audit_period = month # # Start and use a daemon that can run the commands that need to be run with # root privileges. This option is usually enabled on nodes that run nova compute # processes. # (boolean value) #use_rootwrap_daemon = false # # Path to the rootwrap configuration file. # # Goal of the root wrapper is to allow a service-specific unprivileged user to # run a number of actions as the root user in the safest manner possible. # The configuration file used here must match the one defined in the sudoers # entry. # (string value) #rootwrap_config = /etc/nova/rootwrap.conf # Explicitly specify the temporary working directory. (string value) #tempdir = # DEPRECATED: # Determine if monkey patching should be applied. # # Related options: # # * ``monkey_patch_modules``: This must have values set for this option to # have any effect # (boolean value) # This option is deprecated for removal since 17.0.0. # Its value may be silently ignored in the future. # Reason: # Monkey patching nova is not tested, not supported, and is a barrier # for interoperability. #monkey_patch = false # DEPRECATED: # List of modules/decorators to monkey patch. # # This option allows you to patch a decorator for all functions in specified # modules. # # Possible values: # # * nova.compute.api:nova.notifications.notify_decorator # * [...] # # Related options: # # * ``monkey_patch``: This must be set to ``True`` for this option to # have any effect # (list value) # This option is deprecated for removal since 17.0.0. # Its value may be silently ignored in the future. # Reason: # Monkey patching nova is not tested, not supported, and is a barrier # for interoperability. #monkey_patch_modules = nova.compute.api:nova.notifications.notify_decorator # # Defines which driver to use for controlling virtualization. # # Possible values: # # * ``libvirt.LibvirtDriver`` # * ``xenapi.XenAPIDriver`` # * ``fake.FakeDriver`` # * ``ironic.IronicDriver`` # * ``vmwareapi.VMwareVCDriver`` # * ``hyperv.HyperVDriver`` # * ``powervm.PowerVMDriver`` # (string value) #compute_driver = # # Allow destination machine to match source for resize. Useful when # testing in single-host environments. By default it is not allowed # to resize to the same host. Setting this option to true will add # the same host to the destination options. Also set to true # if you allow the ServerGroupAffinityFilter and need to resize. # (boolean value) #allow_resize_to_same_host = false # # Image properties that should not be inherited from the instance # when taking a snapshot. # # This option gives an opportunity to select which image-properties # should not be inherited by newly created snapshots. # # Possible values: # # * A comma-separated list whose item is an image property. Usually only # the image properties that are only needed by base images can be included # here, since the snapshots that are created from the base images don't # need them. # * Default list: cache_in_nova, bittorrent, img_signature_hash_method, # img_signature, img_signature_key_type, # img_signature_certificate_uuid # # (list value) #non_inheritable_image_properties = cache_in_nova,bittorrent,img_signature_hash_method,img_signature,img_signature_key_type,img_signature_certificate_uuid # DEPRECATED: # When creating multiple instances with a single request using the # os-multiple-create API extension, this template will be used to build # the display name for each instance. The benefit is that the instances # end up with different hostnames. Example display names when creating # two VM's: name-1, name-2. # # Possible values: # # * Valid keys for the template are: name, uuid, count. # (string value) # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # This config changes API behaviour. All changes in API behaviour should be # discoverable. #multi_instance_display_name_template = %(name)s-%(count)d # # Maximum number of devices that will result in a local image being # created on the hypervisor node. # # A negative number means unlimited. Setting max_local_block_devices # to 0 means that any request that attempts to create a local disk # will fail. This option is meant to limit the number of local discs # (so root local disc that is the result of --image being used, and # any other ephemeral and swap disks). 0 does not mean that images # will be automatically converted to volumes and boot instances from # volumes - it just means that all requests that attempt to create a # local disk will fail. # # Possible values: # # * 0: Creating a local disk is not allowed. # * Negative number: Allows unlimited number of local discs. # * Positive number: Allows only these many number of local discs. # (Default value is 3). # (integer value) #max_local_block_devices = 3 # # A comma-separated list of monitors that can be used for getting # compute metrics. You can use the alias/name from the setuptools # entry points for nova.compute.monitors.* namespaces. If no # namespace is supplied, the "cpu." namespace is assumed for # backwards-compatibility. # # NOTE: Only one monitor per namespace (For example: cpu) can be loaded at # a time. # # Possible values: # # * An empty list will disable the feature (Default). # * An example value that would enable both the CPU and NUMA memory # bandwidth monitors that use the virt driver variant: # # compute_monitors = cpu.virt_driver, numa_mem_bw.virt_driver # (list value) #compute_monitors = # # The default format an ephemeral_volume will be formatted with on creation. # # Possible values: # # * ``ext2`` # * ``ext3`` # * ``ext4`` # * ``xfs`` # * ``ntfs`` (only for Windows guests) # (string value) #default_ephemeral_format = # # Determine if instance should boot or fail on VIF plugging timeout. # # Nova sends a port update to Neutron after an instance has been scheduled, # providing Neutron with the necessary information to finish setup of the port. # Once completed, Neutron notifies Nova that it has finished setting up the # port, at which point Nova resumes the boot of the instance since network # connectivity is now supposed to be present. A timeout will occur if the reply # is not received after a given interval. # # This option determines what Nova does when the VIF plugging timeout event # happens. When enabled, the instance will error out. When disabled, the # instance will continue to boot on the assumption that the port is ready. # # Possible values: # # * True: Instances should fail after VIF plugging timeout # * False: Instances should continue booting after VIF plugging timeout # (boolean value) #vif_plugging_is_fatal = true # # Timeout for Neutron VIF plugging event message arrival. # # Number of seconds to wait for Neutron vif plugging events to # arrive before continuing or failing (see 'vif_plugging_is_fatal'). # # Related options: # # * vif_plugging_is_fatal - If ``vif_plugging_timeout`` is set to zero and # ``vif_plugging_is_fatal`` is False, events should not be expected to # arrive at all. # (integer value) # Minimum value: 0 #vif_plugging_timeout = 300 # Path to '/etc/network/interfaces' template. # # The path to a template file for the '/etc/network/interfaces'-style file, # which # will be populated by nova and subsequently used by cloudinit. This provides a # method to configure network connectivity in environments without a DHCP # server. # # The template will be rendered using Jinja2 template engine, and receive a # top-level key called ``interfaces``. This key will contain a list of # dictionaries, one for each interface. # # Refer to the cloudinit documentaion for more information: # # https://cloudinit.readthedocs.io/en/latest/topics/datasources.html # # Possible values: # # * A path to a Jinja2-formatted template for a Debian '/etc/network/interfaces' # file. This applies even if using a non Debian-derived guest. # # Related options: # # * ``flat_inject``: This must be set to ``True`` to ensure nova embeds network # configuration information in the metadata provided through the config drive. # (string value) #injected_network_template = $pybasedir/nova/virt/interfaces.template # # The image preallocation mode to use. # # Image preallocation allows storage for instance images to be allocated up # front # when the instance is initially provisioned. This ensures immediate feedback is # given if enough space isn't available. In addition, it should significantly # improve performance on writes to new blocks and may even improve I/O # performance to prewritten blocks due to reduced fragmentation. # # Possible values: # # * "none" => no storage provisioning is done up front # * "space" => storage is fully allocated at instance start # (string value) # Possible values: # none - # space - #preallocate_images = none # # Enable use of copy-on-write (cow) images. # # QEMU/KVM allow the use of qcow2 as backing files. By disabling this, # backing files will not be used. # (boolean value) #use_cow_images = true # # Force conversion of backing images to raw format. # # Possible values: # # * True: Backing image files will be converted to raw image format # * False: Backing image files will not be converted # # Related options: # # * ``compute_driver``: Only the libvirt driver uses this option. # (boolean value) #force_raw_images = true # # Name of the mkfs commands for ephemeral device. # # The format is = # (multi valued) #virt_mkfs = # # Enable resizing of filesystems via a block device. # # If enabled, attempt to resize the filesystem by accessing the image over a # block device. This is done by the host and may not be necessary if the image # contains a recent version of cloud-init. Possible mechanisms require the nbd # driver (for qcow and raw), or loop (for raw). # (boolean value) #resize_fs_using_block_device = false # Amount of time, in seconds, to wait for NBD device start up. (integer value) # Minimum value: 0 #timeout_nbd = 10 # # Location of cached images. # # This is NOT the full path - just a folder name relative to '$instances_path'. # For per-compute-host cached images, set to '_base_$my_ip' # (string value) #image_cache_subdirectory_name = _base # Should unused base images be removed? (boolean value) #remove_unused_base_images = true # # Unused unresized base images younger than this will not be removed. # (integer value) #remove_unused_original_minimum_age_seconds = 86400 # # Generic property to specify the pointer type. # # Input devices allow interaction with a graphical framebuffer. For # example to provide a graphic tablet for absolute cursor movement. # # If set, the 'hw_pointer_model' image property takes precedence over # this configuration option. # # Possible values: # # * None: Uses default behavior provided by drivers (mouse on PS2 for # libvirt x86) # * ps2mouse: Uses relative movement. Mouse connected by PS2 # * usbtablet: Uses absolute movement. Tablet connect by USB # # Related options: # # * usbtablet must be configured with VNC enabled or SPICE enabled and SPICE # agent disabled. When used with libvirt the instance mode should be # configured as HVM. # (string value) # Possible values: # - # ps2mouse - # usbtablet - #pointer_model = usbtablet # # Defines which physical CPUs (pCPUs) can be used by instance # virtual CPUs (vCPUs). # # Possible values: # # * A comma-separated list of physical CPU numbers that virtual CPUs can be # allocated to by default. Each element should be either a single CPU number, # a range of CPU numbers, or a caret followed by a CPU number to be # excluded from a previous range. For example: # # vcpu_pin_set = "4-12,^8,15" # (string value) #vcpu_pin_set = # # Number of huge/large memory pages to reserved per NUMA host cell. # # Possible values: # # * A list of valid key=value which reflect NUMA node ID, page size # (Default unit is KiB) and number of pages to be reserved. # # reserved_huge_pages = node:0,size:2048,count:64 # reserved_huge_pages = node:1,size:1GB,count:1 # # In this example we are reserving on NUMA node 0 64 pages of 2MiB # and on NUMA node 1 1 page of 1GiB. # (dict value) #reserved_huge_pages = # # Amount of disk resources in MB to make them always available to host. The # disk usage gets reported back to the scheduler from nova-compute running # on the compute nodes. To prevent the disk resources from being considered # as available, this option can be used to reserve disk space for that host. # # Possible values: # # * Any positive integer representing amount of disk in MB to reserve # for the host. # (integer value) # Minimum value: 0 #reserved_host_disk_mb = 0 # # Amount of memory in MB to reserve for the host so that it is always available # to host processes. The host resources usage is reported back to the scheduler # continuously from nova-compute running on the compute node. To prevent the # host # memory from being considered as available, this option is used to reserve # memory for the host. # # Possible values: # # * Any positive integer representing amount of memory in MB to reserve # for the host. # (integer value) # Minimum value: 0 #reserved_host_memory_mb = 512 # # Number of physical CPUs to reserve for the host. The host resources usage is # reported back to the scheduler continuously from nova-compute running on the # compute node. To prevent the host CPU from being considered as available, # this option is used to reserve random pCPU(s) for the host. # # Possible values: # # * Any positive integer representing number of physical CPUs to reserve # for the host. # (integer value) # Minimum value: 0 #reserved_host_cpus = 0 # # This option helps you specify virtual CPU to physical CPU allocation ratio. # # From Ocata (15.0.0) this is used to influence the hosts selected by # the Placement API. Note that when Placement is used, the CoreFilter # is redundant, because the Placement API will have already filtered # out hosts that would have failed the CoreFilter. # # This configuration specifies ratio for CoreFilter which can be set # per compute node. For AggregateCoreFilter, it will fall back to this # configuration value if no per-aggregate setting is found. # # NOTE: This can be set per-compute, or if set to 0.0, the value # set on the scheduler node(s) or compute node(s) will be used # and defaulted to 16.0. Once set to a non-default value, it is not possible # to "unset" the config to get back to the default behavior. If you want # to reset back to the default, explicitly specify 16.0. # # NOTE: As of the 16.0.0 Pike release, this configuration option is ignored # for the ironic.IronicDriver compute driver and is hardcoded to 1.0. # # Possible values: # # * Any valid positive integer or float value # (floating point value) # Minimum value: 0 #cpu_allocation_ratio = 0.0 # # This option helps you specify virtual RAM to physical RAM # allocation ratio. # # From Ocata (15.0.0) this is used to influence the hosts selected by # the Placement API. Note that when Placement is used, the RamFilter # is redundant, because the Placement API will have already filtered # out hosts that would have failed the RamFilter. # # This configuration specifies ratio for RamFilter which can be set # per compute node. For AggregateRamFilter, it will fall back to this # configuration value if no per-aggregate setting found. # # NOTE: This can be set per-compute, or if set to 0.0, the value # set on the scheduler node(s) or compute node(s) will be used and # defaulted to 1.5. Once set to a non-default value, it is not possible # to "unset" the config to get back to the default behavior. If you want # to reset back to the default, explicitly specify 1.5. # # NOTE: As of the 16.0.0 Pike release, this configuration option is ignored # for the ironic.IronicDriver compute driver and is hardcoded to 1.0. # # Possible values: # # * Any valid positive integer or float value # (floating point value) # Minimum value: 0 #ram_allocation_ratio = 0.0 # # This option helps you specify virtual disk to physical disk # allocation ratio. # # From Ocata (15.0.0) this is used to influence the hosts selected by # the Placement API. Note that when Placement is used, the DiskFilter # is redundant, because the Placement API will have already filtered # out hosts that would have failed the DiskFilter. # # A ratio greater than 1.0 will result in over-subscription of the # available physical disk, which can be useful for more # efficiently packing instances created with images that do not # use the entire virtual disk, such as sparse or compressed # images. It can be set to a value between 0.0 and 1.0 in order # to preserve a percentage of the disk for uses other than # instances. # # NOTE: This can be set per-compute, or if set to 0.0, the value # set on the scheduler node(s) or compute node(s) will be used and # defaulted to 1.0. Once set to a non-default value, it is not possible # to "unset" the config to get back to the default behavior. If you want # to reset back to the default, explicitly specify 1.0. # # NOTE: As of the 16.0.0 Pike release, this configuration option is ignored # for the ironic.IronicDriver compute driver and is hardcoded to 1.0. # # Possible values: # # * Any valid positive integer or float value # (floating point value) # Minimum value: 0 #disk_allocation_ratio = 0.0 # # Console proxy host to be used to connect to instances on this host. It is the # publicly visible name for the console host. # # Possible values: # # * Current hostname (default) or any string representing hostname. # (string value) #console_host = # # Name of the network to be used to set access IPs for instances. If there are # multiple IPs to choose from, an arbitrary one will be chosen. # # Possible values: # # * None (default) # * Any string representing network name. # (string value) #default_access_ip_network_name = # # Whether to batch up the application of IPTables rules during a host restart # and apply all at the end of the init phase. # (boolean value) #defer_iptables_apply = false # # Specifies where instances are stored on the hypervisor's disk. # It can point to locally attached storage or a directory on NFS. # # Possible values: # # * $state_path/instances where state_path is a config option that specifies # the top-level directory for maintaining nova's state. (default) or # Any string representing directory path. # # Related options: # # * ``[workarounds]/ensure_libvirt_rbd_instance_dir_cleanup`` # (string value) #instances_path = $state_path/instances # # This option enables periodic compute.instance.exists notifications. Each # compute node must be configured to generate system usage data. These # notifications are consumed by OpenStack Telemetry service. # (boolean value) #instance_usage_audit = false # # Maximum number of 1 second retries in live_migration. It specifies number # of retries to iptables when it complains. It happens when an user continuously # sends live-migration request to same host leading to concurrent request # to iptables. # # Possible values: # # * Any positive integer representing retry count. # (integer value) # Minimum value: 0 #live_migration_retry_count = 30 # # This option specifies whether to start guests that were running before the # host rebooted. It ensures that all of the instances on a Nova compute node # resume their state each time the compute node boots or restarts. # (boolean value) #resume_guests_state_on_host_boot = false # # Number of times to retry network allocation. It is required to attempt network # allocation retries if the virtual interface plug fails. # # Possible values: # # * Any positive integer representing retry count. # (integer value) # Minimum value: 0 #network_allocate_retries = 0 # # Limits the maximum number of instance builds to run concurrently by # nova-compute. Compute service can attempt to build an infinite number of # instances, if asked to do so. This limit is enforced to avoid building # unlimited instance concurrently on a compute node. This value can be set # per compute node. # # Possible Values: # # * 0 : treated as unlimited. # * Any positive integer representing maximum concurrent builds. # (integer value) # Minimum value: 0 #max_concurrent_builds = 10 # # Maximum number of live migrations to run concurrently. This limit is enforced # to avoid outbound live migrations overwhelming the host/network and causing # failures. It is not recommended that you change this unless you are very sure # that doing so is safe and stable in your environment. # # Possible values: # # * 0 : treated as unlimited. # * Negative value defaults to 0. # * Any positive integer representing maximum number of live migrations # to run concurrently. # (integer value) #max_concurrent_live_migrations = 1 # # Number of times to retry block device allocation on failures. Starting with # Liberty, Cinder can use image volume cache. This may help with block device # allocation performance. Look at the cinder image_volume_cache_enabled # configuration option. # # Possible values: # # * 60 (default) # * If value is 0, then one attempt is made. # * Any negative value is treated as 0. # * For any value > 0, total attempts are (value + 1) # (integer value) #block_device_allocate_retries = 60 # # Number of greenthreads available for use to sync power states. # # This option can be used to reduce the number of concurrent requests # made to the hypervisor or system with real instance power states # for performance reasons, for example, with Ironic. # # Possible values: # # * Any positive integer representing greenthreads count. # (integer value) #sync_power_state_pool_size = 1000 # # Number of seconds to wait between runs of the image cache manager. # # Possible values: # * 0: run at the default rate. # * -1: disable # * Any other value # (integer value) # Minimum value: -1 #image_cache_manager_interval = 2400 # # Interval to pull network bandwidth usage info. # # Not supported on all hypervisors. If a hypervisor doesn't support bandwidth # usage, it will not get the info in the usage events. # # Possible values: # # * 0: Will run at the default periodic interval. # * Any value < 0: Disables the option. # * Any positive integer in seconds. # (integer value) #bandwidth_poll_interval = 600 # # Interval to sync power states between the database and the hypervisor. # # The interval that Nova checks the actual virtual machine power state # and the power state that Nova has in its database. If a user powers # down their VM, Nova updates the API to report the VM has been # powered down. Should something turn on the VM unexpectedly, # Nova will turn the VM back off to keep the system in the expected # state. # # Possible values: # # * 0: Will run at the default periodic interval. # * Any value < 0: Disables the option. # * Any positive integer in seconds. # # Related options: # # * If ``handle_virt_lifecycle_events`` in workarounds_group is # false and this option is negative, then instances that get out # of sync between the hypervisor and the Nova database will have # to be synchronized manually. # (integer value) #sync_power_state_interval = 600 # # Interval between instance network information cache updates. # # Number of seconds after which each compute node runs the task of # querying Neutron for all of its instances networking information, # then updates the Nova db with that information. Nova will never # update it's cache if this option is set to 0. If we don't update the # cache, the metadata service and nova-api endpoints will be proxying # incorrect network data about the instance. So, it is not recommended # to set this option to 0. # # Possible values: # # * Any positive integer in seconds. # * Any value <=0 will disable the sync. This is not recommended. # (integer value) #heal_instance_info_cache_interval = 60 # # Interval for reclaiming deleted instances. # # A value greater than 0 will enable SOFT_DELETE of instances. # This option decides whether the server to be deleted will be put into # the SOFT_DELETED state. If this value is greater than 0, the deleted # server will not be deleted immediately, instead it will be put into # a queue until it's too old (deleted time greater than the value of # reclaim_instance_interval). The server can be recovered from the # delete queue by using the restore action. If the deleted server remains # longer than the value of reclaim_instance_interval, it will be # deleted by a periodic task in the compute service automatically. # # Note that this option is read from both the API and compute nodes, and # must be set globally otherwise servers could be put into a soft deleted # state in the API and never actually reclaimed (deleted) on the compute # node. # # Possible values: # # * Any positive integer(in seconds) greater than 0 will enable # this option. # * Any value <=0 will disable the option. # (integer value) #reclaim_instance_interval = 0 # # Interval for gathering volume usages. # # This option updates the volume usage cache for every # volume_usage_poll_interval number of seconds. # # Possible values: # # * Any positive integer(in seconds) greater than 0 will enable # this option. # * Any value <=0 will disable the option. # (integer value) #volume_usage_poll_interval = 0 # # Interval for polling shelved instances to offload. # # The periodic task runs for every shelved_poll_interval number # of seconds and checks if there are any shelved instances. If it # finds a shelved instance, based on the 'shelved_offload_time' config # value it offloads the shelved instances. Check 'shelved_offload_time' # config option description for details. # # Possible values: # # * Any value <= 0: Disables the option. # * Any positive integer in seconds. # # Related options: # # * ``shelved_offload_time`` # (integer value) #shelved_poll_interval = 3600 # # Time before a shelved instance is eligible for removal from a host. # # By default this option is set to 0 and the shelved instance will be # removed from the hypervisor immediately after shelve operation. # Otherwise, the instance will be kept for the value of # shelved_offload_time(in seconds) so that during the time period the # unshelve action will be faster, then the periodic task will remove # the instance from hypervisor after shelved_offload_time passes. # # Possible values: # # * 0: Instance will be immediately offloaded after being # shelved. # * Any value < 0: An instance will never offload. # * Any positive integer in seconds: The instance will exist for # the specified number of seconds before being offloaded. # (integer value) #shelved_offload_time = 0 # # Interval for retrying failed instance file deletes. # # This option depends on 'maximum_instance_delete_attempts'. # This option specifies how often to retry deletes whereas # 'maximum_instance_delete_attempts' specifies the maximum number # of retry attempts that can be made. # # Possible values: # # * 0: Will run at the default periodic interval. # * Any value < 0: Disables the option. # * Any positive integer in seconds. # # Related options: # # * ``maximum_instance_delete_attempts`` from instance_cleaning_opts # group. # (integer value) #instance_delete_interval = 300 # # Interval (in seconds) between block device allocation retries on failures. # # This option allows the user to specify the time interval between # consecutive retries. 'block_device_allocate_retries' option specifies # the maximum number of retries. # # Possible values: # # * 0: Disables the option. # * Any positive integer in seconds enables the option. # # Related options: # # * ``block_device_allocate_retries`` in compute_manager_opts group. # (integer value) # Minimum value: 0 #block_device_allocate_retries_interval = 3 # # Interval between sending the scheduler a list of current instance UUIDs to # verify that its view of instances is in sync with nova. # # If the CONF option 'scheduler_tracks_instance_changes' is # False, the sync calls will not be made. So, changing this option will # have no effect. # # If the out of sync situations are not very common, this interval # can be increased to lower the number of RPC messages being sent. # Likewise, if sync issues turn out to be a problem, the interval # can be lowered to check more frequently. # # Possible values: # # * 0: Will run at the default periodic interval. # * Any value < 0: Disables the option. # * Any positive integer in seconds. # # Related options: # # * This option has no impact if ``scheduler_tracks_instance_changes`` # is set to False. # (integer value) #scheduler_instance_sync_interval = 120 # # Interval for updating compute resources. # # This option specifies how often the update_available_resources # periodic task should run. A number less than 0 means to disable the # task completely. Leaving this at the default of 0 will cause this to # run at the default periodic interval. Setting it to any positive # value will cause it to run at approximately that number of seconds. # # Possible values: # # * 0: Will run at the default periodic interval. # * Any value < 0: Disables the option. # * Any positive integer in seconds. # (integer value) #update_resources_interval = 0 # # Time interval after which an instance is hard rebooted automatically. # # When doing a soft reboot, it is possible that a guest kernel is # completely hung in a way that causes the soft reboot task # to not ever finish. Setting this option to a time period in seconds # will automatically hard reboot an instance if it has been stuck # in a rebooting state longer than N seconds. # # Possible values: # # * 0: Disables the option (default). # * Any positive integer in seconds: Enables the option. # (integer value) # Minimum value: 0 #reboot_timeout = 0 # # Maximum time in seconds that an instance can take to build. # # If this timer expires, instance status will be changed to ERROR. # Enabling this option will make sure an instance will not be stuck # in BUILD state for a longer period. # # Possible values: # # * 0: Disables the option (default) # * Any positive integer in seconds: Enables the option. # (integer value) # Minimum value: 0 #instance_build_timeout = 0 # # Interval to wait before un-rescuing an instance stuck in RESCUE. # # Possible values: # # * 0: Disables the option (default) # * Any positive integer in seconds: Enables the option. # (integer value) # Minimum value: 0 #rescue_timeout = 0 # # Automatically confirm resizes after N seconds. # # Resize functionality will save the existing server before resizing. # After the resize completes, user is requested to confirm the resize. # The user has the opportunity to either confirm or revert all # changes. Confirm resize removes the original server and changes # server status from resized to active. Setting this option to a time # period (in seconds) will automatically confirm the resize if the # server is in resized state longer than that time. # # Possible values: # # * 0: Disables the option (default) # * Any positive integer in seconds: Enables the option. # (integer value) # Minimum value: 0 #resize_confirm_window = 0 # # Total time to wait in seconds for an instance toperform a clean # shutdown. # # It determines the overall period (in seconds) a VM is allowed to # perform a clean shutdown. While performing stop, rescue and shelve, # rebuild operations, configuring this option gives the VM a chance # to perform a controlled shutdown before the instance is powered off. # The default timeout is 60 seconds. # # The timeout value can be overridden on a per image basis by means # of os_shutdown_timeout that is an image metadata setting allowing # different types of operating systems to specify how much time they # need to shut down cleanly. # # Possible values: # # * Any positive integer in seconds (default value is 60). # (integer value) # Minimum value: 1 #shutdown_timeout = 60 # # The compute service periodically checks for instances that have been # deleted in the database but remain running on the compute node. The # above option enables action to be taken when such instances are # identified. # # Possible values: # # * reap: Powers down the instances and deletes them(default) # * log: Logs warning message about deletion of the resource # * shutdown: Powers down instances and marks them as non- # bootable which can be later used for debugging/analysis # * noop: Takes no action # # Related options: # # * running_deleted_instance_poll_interval # * running_deleted_instance_timeout # (string value) # Possible values: # noop - # log - # shutdown - # reap - #running_deleted_instance_action = reap # # Time interval in seconds to wait between runs for the clean up action. # If set to 0, above check will be disabled. If "running_deleted_instance # _action" is set to "log" or "reap", a value greater than 0 must be set. # # Possible values: # # * Any positive integer in seconds enables the option. # * 0: Disables the option. # * 1800: Default value. # # Related options: # # * running_deleted_instance_action # (integer value) #running_deleted_instance_poll_interval = 1800 # # Time interval in seconds to wait for the instances that have # been marked as deleted in database to be eligible for cleanup. # # Possible values: # # * Any positive integer in seconds(default is 0). # # Related options: # # * "running_deleted_instance_action" # (integer value) #running_deleted_instance_timeout = 0 # # The number of times to attempt to reap an instance's files. # # This option specifies the maximum number of retry attempts # that can be made. # # Possible values: # # * Any positive integer defines how many attempts are made. # * Any value <=0 means no delete attempts occur, but you should use # ``instance_delete_interval`` to disable the delete attempts. # # Related options: # * ``instance_delete_interval`` in interval_opts group can be used to disable # this option. # (integer value) #maximum_instance_delete_attempts = 5 # # Sets the scope of the check for unique instance names. # # The default doesn't check for unique names. If a scope for the name check is # set, a launch of a new instance or an update of an existing instance with a # duplicate name will result in an ''InstanceExists'' error. The uniqueness is # case-insensitive. Setting this option can increase the usability for end # users as they don't have to distinguish among instances with the same name # by their IDs. # # Possible values: # # * '': An empty value means that no uniqueness check is done and duplicate # names are possible. # * "project": The instance name check is done only for instances within the # same project. # * "global": The instance name check is done for all instances regardless of # the project. # (string value) # Possible values: # '' - # project - # global - #osapi_compute_unique_server_name_scope = # # Enable new nova-compute services on this host automatically. # # When a new nova-compute service starts up, it gets # registered in the database as an enabled service. Sometimes it can be useful # to register new compute services in disabled state and then enabled them at a # later point in time. This option only sets this behavior for nova-compute # services, it does not auto-disable other services like nova-conductor, # nova-scheduler, nova-consoleauth, or nova-osapi_compute. # # Possible values: # # * ``True``: Each new compute service is enabled as soon as it registers # itself. # * ``False``: Compute services must be enabled via an os-services REST API call # or with the CLI with ``nova service-enable ``, otherwise # they are not ready to use. # (boolean value) #enable_new_services = true # # Template string to be used to generate instance names. # # This template controls the creation of the database name of an instance. This # is *not* the display name you enter when creating an instance (via Horizon # or CLI). For a new deployment it is advisable to change the default value # (which uses the database autoincrement) to another value which makes use # of the attributes of an instance, like ``instance-%(uuid)s``. If you # already have instances in your deployment when you change this, your # deployment will break. # # Possible values: # # * A string which either uses the instance database ID (like the # default) # * A string with a list of named database columns, for example ``%(id)d`` # or ``%(uuid)s`` or ``%(hostname)s``. # # Related options: # # * not to be confused with: ``multi_instance_display_name_template`` # (string value) #instance_name_template = instance-%08x # # Number of times to retry live-migration before failing. # # Possible values: # # * If == -1, try until out of hosts (default) # * If == 0, only try once, no retries # * Integer greater than 0 # (integer value) # Minimum value: -1 #migrate_max_retries = -1 # # Configuration drive format # # Configuration drive format that will contain metadata attached to the # instance when it boots. # # Possible values: # # * iso9660: A file system image standard that is widely supported across # operating systems. NOTE: Mind the libvirt bug # (https://bugs.launchpad.net/nova/+bug/1246201) - If your hypervisor # driver is libvirt, and you want live migrate to work without shared storage, # then use VFAT. # * vfat: For legacy reasons, you can configure the configuration drive to # use VFAT format instead of ISO 9660. # # Related options: # # * This option is meaningful when one of the following alternatives occur: # 1. force_config_drive option set to 'true' # 2. the REST API call to create the instance contains an enable flag for # config drive option # 3. the image used to create the instance requires a config drive, # this is defined by img_config_drive property for that image. # * A compute node running Hyper-V hypervisor can be configured to attach # configuration drive as a CD drive. To attach the configuration drive as a CD # drive, set config_drive_cdrom option at hyperv section, to true. # (string value) # Possible values: # iso9660 - # vfat - #config_drive_format = iso9660 # # Force injection to take place on a config drive # # When this option is set to true configuration drive functionality will be # forced enabled by default, otherwise user can still enable configuration # drives via the REST API or image metadata properties. # # Possible values: # # * True: Force to use of configuration drive regardless the user's input in the # REST API call. # * False: Do not force use of configuration drive. Config drives can still be # enabled via the REST API or image metadata properties. # # Related options: # # * Use the 'mkisofs_cmd' flag to set the path where you install the # genisoimage program. If genisoimage is in same path as the # nova-compute service, you do not need to set this flag. # * To use configuration drive with Hyper-V, you must set the # 'mkisofs_cmd' value to the full path to an mkisofs.exe installation. # Additionally, you must set the qemu_img_cmd value in the hyperv # configuration section to the full path to an qemu-img command # installation. # (boolean value) #force_config_drive = false # # Name or path of the tool used for ISO image creation # # Use the mkisofs_cmd flag to set the path where you install the genisoimage # program. If genisoimage is on the system path, you do not need to change # the default value. # # To use configuration drive with Hyper-V, you must set the mkisofs_cmd value # to the full path to an mkisofs.exe installation. Additionally, you must set # the qemu_img_cmd value in the hyperv configuration section to the full path # to an qemu-img command installation. # # Possible values: # # * Name of the ISO image creator program, in case it is in the same directory # as the nova-compute service # * Path to ISO image creator program # # Related options: # # * This option is meaningful when config drives are enabled. # * To use configuration drive with Hyper-V, you must set the qemu_img_cmd # value in the hyperv configuration section to the full path to an qemu-img # command installation. # (string value) #mkisofs_cmd = genisoimage # DEPRECATED: The driver to use for database access (string value) # This option is deprecated for removal since 13.0.0. # Its value may be silently ignored in the future. #db_driver = nova.db # DEPRECATED: # Default flavor to use for the EC2 API only. # The Nova API does not support a default flavor. # (string value) # This option is deprecated for removal since 14.0.0. # Its value may be silently ignored in the future. # Reason: The EC2 API is deprecated. #default_flavor = m1.small # # The IP address which the host is using to connect to the management network. # # Possible values: # # * String with valid IP address. Default is IPv4 address of this host. # # Related options: # # * metadata_host # * my_block_storage_ip # * routing_source_ip # * vpn_ip # (string value) #my_ip = # # The IP address which is used to connect to the block storage network. # # Possible values: # # * String with valid IP address. Default is IP address of this host. # # Related options: # # * my_ip - if my_block_storage_ip is not set, then my_ip value is used. # (string value) #my_block_storage_ip = $my_ip # # Hostname, FQDN or IP address of this host. # # Used as: # # * the oslo.messaging queue name for nova-compute worker # * we use this value for the binding_host sent to neutron. This means if you # use # a neutron agent, it should have the same value for host. # * cinder host attachment information # # Must be valid within AMQP key. # # Possible values: # # * String with hostname, FQDN or IP address. Default is hostname of this host. # (string value) #host = # DEPRECATED: # This option is a list of full paths to one or more configuration files for # dhcpbridge. In most cases the default path of '/etc/nova/nova-dhcpbridge.conf' # should be sufficient, but if you have special needs for configuring # dhcpbridge, # you can change or add to this list. # # Possible values # # * A list of strings, where each string is the full path to a dhcpbridge # configuration file. # (multi valued) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #dhcpbridge_flagfile = /etc/nova/nova-dhcpbridge.conf # DEPRECATED: # The location where the network configuration files will be kept. The default # is # the 'networks' directory off of the location where nova's Python module is # installed. # # Possible values # # * A string containing the full path to the desired configuration directory # (string value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #networks_path = $state_path/networks # DEPRECATED: # This is the name of the network interface for public IP addresses. The default # is 'eth0'. # # Possible values: # # * Any string representing a network interface name # (string value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #public_interface = eth0 # DEPRECATED: # The location of the binary nova-dhcpbridge. By default it is the binary named # 'nova-dhcpbridge' that is installed with all the other nova binaries. # # Possible values: # # * Any string representing the full path to the binary for dhcpbridge # (string value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #dhcpbridge = $bindir/nova-dhcpbridge # DEPRECATED: # The public IP address of the network host. # # This is used when creating an SNAT rule. # # Possible values: # # * Any valid IP address # # Related options: # # * ``force_snat_range`` # (string value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #routing_source_ip = $my_ip # DEPRECATED: # The lifetime of a DHCP lease, in seconds. The default is 86400 (one day). # # Possible values: # # * Any positive integer value. # (integer value) # Minimum value: 1 # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #dhcp_lease_time = 86400 # DEPRECATED: # Despite the singular form of the name of this option, it is actually a list of # zero or more server addresses that dnsmasq will use for DNS nameservers. If # this is not empty, dnsmasq will not read /etc/resolv.conf, but will only use # the servers specified in this option. If the option use_network_dns_servers is # True, the dns1 and dns2 servers from the network will be appended to this # list, # and will be used as DNS servers, too. # # Possible values: # # * A list of strings, where each string is either an IP address or a FQDN. # # Related options: # # * ``use_network_dns_servers`` # (multi valued) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #dns_server = # DEPRECATED: # When this option is set to True, the dns1 and dns2 servers for the network # specified by the user on boot will be used for DNS, as well as any specified # in # the `dns_server` option. # # Related options: # # * ``dns_server`` # (boolean value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #use_network_dns_servers = false # DEPRECATED: # This option is a list of zero or more IP address ranges in your network's DMZ # that should be accepted. # # Possible values: # # * A list of strings, each of which should be a valid CIDR. # (list value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #dmz_cidr = # DEPRECATED: # This is a list of zero or more IP ranges that traffic from the # `routing_source_ip` will be SNATted to. If the list is empty, then no SNAT # rules are created. # # Possible values: # # * A list of strings, each of which should be a valid CIDR. # # Related options: # # * ``routing_source_ip`` # (multi valued) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #force_snat_range = # DEPRECATED: # The path to the custom dnsmasq configuration file, if any. # # Possible values: # # * The full path to the configuration file, or an empty string if there is no # custom dnsmasq configuration file. # (string value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #dnsmasq_config_file = # DEPRECATED: # This is the class used as the ethernet device driver for linuxnet bridge # operations. The default value should be all you need for most cases, but if # you # wish to use a customized class, set this option to the full dot-separated # import path for that class. # # Possible values: # # * Any string representing a dot-separated class path that Nova can import. # (string value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #linuxnet_interface_driver = nova.network.linux_net.LinuxBridgeInterfaceDriver # DEPRECATED: # The name of the Open vSwitch bridge that is used with linuxnet when connecting # with Open vSwitch." # # Possible values: # # * Any string representing a valid bridge name. # (string value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #linuxnet_ovs_integration_bridge = br-int # # When True, when a device starts up, and upon binding floating IP addresses, # arp # messages will be sent to ensure that the arp caches on the compute hosts are # up-to-date. # # Related options: # # * ``send_arp_for_ha_count`` # (boolean value) #send_arp_for_ha = false # # When arp messages are configured to be sent, they will be sent with the count # set to the value of this option. Of course, if this is set to zero, no arp # messages will be sent. # # Possible values: # # * Any integer greater than or equal to 0 # # Related options: # # * ``send_arp_for_ha`` # (integer value) #send_arp_for_ha_count = 3 # DEPRECATED: # When set to True, only the firt nic of a VM will get its default gateway from # the DHCP server. # (boolean value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #use_single_default_gateway = false # DEPRECATED: # One or more interfaces that bridges can forward traffic to. If any of the # items # in this list is the special keyword 'all', then all traffic will be forwarded. # # Possible values: # # * A list of zero or more interface names, or the word 'all'. # (multi valued) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #forward_bridge_interface = all # # This option determines the IP address for the network metadata API server. # # This is really the client side of the metadata host equation that allows # nova-network to find the metadata server when doing a default multi host # networking. # # Possible values: # # * Any valid IP address. The default is the address of the Nova API server. # # Related options: # # * ``metadata_port`` # (string value) #metadata_host = $my_ip # DEPRECATED: # This option determines the port used for the metadata API server. # # Related options: # # * ``metadata_host`` # (port value) # Minimum value: 0 # Maximum value: 65535 # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #metadata_port = 8775 # DEPRECATED: # This expression, if defined, will select any matching iptables rules and place # them at the top when applying metadata changes to the rules. # # Possible values: # # * Any string representing a valid regular expression, or an empty string # # Related options: # # * ``iptables_bottom_regex`` # (string value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #iptables_top_regex = # DEPRECATED: # This expression, if defined, will select any matching iptables rules and place # them at the bottom when applying metadata changes to the rules. # # Possible values: # # * Any string representing a valid regular expression, or an empty string # # Related options: # # * iptables_top_regex # (string value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #iptables_bottom_regex = # DEPRECATED: # By default, packets that do not pass the firewall are DROPped. In many cases, # though, an operator may find it more useful to change this from DROP to # REJECT, # so that the user issuing those packets may have a better idea as to what's # going on, or LOGDROP in order to record the blocked traffic before DROPping. # # Possible values: # # * A string representing an iptables chain. The default is DROP. # (string value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #iptables_drop_action = DROP # DEPRECATED: # This option represents the period of time, in seconds, that the ovs_vsctl # calls # will wait for a response from the database before timing out. A setting of 0 # means that the utility should wait forever for a response. # # Possible values: # # * Any positive integer if a limited timeout is desired, or zero if the calls # should wait forever for a response. # (integer value) # Minimum value: 0 # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #ovs_vsctl_timeout = 120 # DEPRECATED: # This option is used mainly in testing to avoid calls to the underlying network # utilities. # (boolean value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #fake_network = false # DEPRECATED: # This option determines the number of times to retry ebtables commands before # giving up. The minimum number of retries is 1. # # Possible values: # # * Any positive integer # # Related options: # # * ``ebtables_retry_interval`` # (integer value) # Minimum value: 1 # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #ebtables_exec_attempts = 3 # DEPRECATED: # This option determines the time, in seconds, that the system will sleep in # between ebtables retries. Note that each successive retry waits a multiple of # this value, so for example, if this is set to the default of 1.0 seconds, and # ebtables_exec_attempts is 4, after the first failure, the system will sleep # for # 1 * 1.0 seconds, after the second failure it will sleep 2 * 1.0 seconds, and # after the third failure it will sleep 3 * 1.0 seconds. # # Possible values: # # * Any non-negative float or integer. Setting this to zero will result in no # waiting between attempts. # # Related options: # # * ebtables_exec_attempts # (floating point value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #ebtables_retry_interval = 1.0 # DEPRECATED: # Enable neutron as the backend for networking. # # Determine whether to use Neutron or Nova Network as the back end. Set to true # to use neutron. # (boolean value) # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #use_neutron = true # # This option determines whether the network setup information is injected into # the VM before it is booted. While it was originally designed to be used only # by nova-network, it is also used by the vmware and xenapi virt drivers to # control whether network information is injected into a VM. The libvirt virt # driver also uses it when we use config_drive to configure network to control # whether network information is injected into a VM. # (boolean value) #flat_injected = false # DEPRECATED: # This option determines the bridge used for simple network interfaces when no # bridge is specified in the VM creation request. # # Please note that this option is only used when using nova-network instead of # Neutron in your deployment. # # Possible values: # # * Any string representing a valid network bridge, such as 'br100' # # Related options: # # * ``use_neutron`` # (string value) # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #flat_network_bridge = # DEPRECATED: # This is the address of the DNS server for a simple network. If this option is # not specified, the default of '8.8.4.4' is used. # # Please note that this option is only used when using nova-network instead of # Neutron in your deployment. # # Possible values: # # * Any valid IP address. # # Related options: # # * ``use_neutron`` # (string value) # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #flat_network_dns = 8.8.4.4 # DEPRECATED: # This option is the name of the virtual interface of the VM on which the bridge # will be built. While it was originally designed to be used only by # nova-network, it is also used by libvirt for the bridge interface name. # # Possible values: # # * Any valid virtual interface name, such as 'eth0' # (string value) # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #flat_interface = # DEPRECATED: # This is the VLAN number used for private networks. Note that the when creating # the networks, if the specified number has already been assigned, nova-network # will increment this number until it finds an available VLAN. # # Please note that this option is only used when using nova-network instead of # Neutron in your deployment. It also will be ignored if the configuration # option # for `network_manager` is not set to the default of # 'nova.network.manager.VlanManager'. # # Possible values: # # * Any integer between 1 and 4094. Values outside of that range will raise a # ValueError exception. # # Related options: # # * ``network_manager`` # * ``use_neutron`` # (integer value) # Minimum value: 1 # Maximum value: 4094 # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #vlan_start = 100 # DEPRECATED: # This option is the name of the virtual interface of the VM on which the VLAN # bridge will be built. While it was originally designed to be used only by # nova-network, it is also used by libvirt and xenapi for the bridge interface # name. # # Please note that this setting will be ignored in nova-network if the # configuration option for `network_manager` is not set to the default of # 'nova.network.manager.VlanManager'. # # Possible values: # # * Any valid virtual interface name, such as 'eth0' # (string value) # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. While # this option has an effect when using neutron, it incorrectly override the # value # provided by neutron and should therefore not be used. #vlan_interface = # DEPRECATED: # This option represents the number of networks to create if not explicitly # specified when the network is created. The only time this is used is if a CIDR # is specified, but an explicit network_size is not. In that case, the subnets # are created by diving the IP address space of the CIDR by num_networks. The # resulting subnet sizes cannot be larger than the configuration option # `network_size`; in that event, they are reduced to `network_size`, and a # warning is logged. # # Please note that this option is only used when using nova-network instead of # Neutron in your deployment. # # Possible values: # # * Any positive integer is technically valid, although there are practical # limits based upon available IP address space and virtual interfaces. # # Related options: # # * ``use_neutron`` # * ``network_size`` # (integer value) # Minimum value: 1 # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #num_networks = 1 # DEPRECATED: # This option is no longer used since the /os-cloudpipe API was removed in the # 16.0.0 Pike release. This is the public IP address for the cloudpipe VPN # servers. It defaults to the IP address of the host. # # Please note that this option is only used when using nova-network instead of # Neutron in your deployment. It also will be ignored if the configuration # option # for `network_manager` is not set to the default of # 'nova.network.manager.VlanManager'. # # Possible values: # # * Any valid IP address. The default is ``$my_ip``, the IP address of the VM. # # Related options: # # * ``network_manager`` # * ``use_neutron`` # * ``vpn_start`` # (string value) # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #vpn_ip = $my_ip # DEPRECATED: # This is the port number to use as the first VPN port for private networks. # # Please note that this option is only used when using nova-network instead of # Neutron in your deployment. It also will be ignored if the configuration # option # for `network_manager` is not set to the default of # 'nova.network.manager.VlanManager', or if you specify a value the 'vpn_start' # parameter when creating a network. # # Possible values: # # * Any integer representing a valid port number. The default is 1000. # # Related options: # # * ``use_neutron`` # * ``vpn_ip`` # * ``network_manager`` # (port value) # Minimum value: 0 # Maximum value: 65535 # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #vpn_start = 1000 # DEPRECATED: # This option determines the number of addresses in each private subnet. # # Please note that this option is only used when using nova-network instead of # Neutron in your deployment. # # Possible values: # # * Any positive integer that is less than or equal to the available network # size. Note that if you are creating multiple networks, they must all fit in # the available IP address space. The default is 256. # # Related options: # # * ``use_neutron`` # * ``num_networks`` # (integer value) # Minimum value: 1 # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #network_size = 256 # DEPRECATED: # This option determines the fixed IPv6 address block when creating a network. # # Please note that this option is only used when using nova-network instead of # Neutron in your deployment. # # Possible values: # # * Any valid IPv6 CIDR # # Related options: # # * ``use_neutron`` # (string value) # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #fixed_range_v6 = fd00::/48 # DEPRECATED: # This is the default IPv4 gateway. It is used only in the testing suite. # # Please note that this option is only used when using nova-network instead of # Neutron in your deployment. # # Possible values: # # * Any valid IP address. # # Related options: # # * ``use_neutron`` # * ``gateway_v6`` # (string value) # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #gateway = # DEPRECATED: # This is the default IPv6 gateway. It is used only in the testing suite. # # Please note that this option is only used when using nova-network instead of # Neutron in your deployment. # # Possible values: # # * Any valid IP address. # # Related options: # # * ``use_neutron`` # * ``gateway`` # (string value) # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #gateway_v6 = # DEPRECATED: # This option represents the number of IP addresses to reserve at the top of the # address range for VPN clients. It also will be ignored if the configuration # option for `network_manager` is not set to the default of # 'nova.network.manager.VlanManager'. # # Possible values: # # * Any integer, 0 or greater. # # Related options: # # * ``use_neutron`` # * ``network_manager`` # (integer value) # Minimum value: 0 # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #cnt_vpn_clients = 0 # DEPRECATED: # This is the number of seconds to wait before disassociating a deallocated # fixed # IP address. This is only used with the nova-network service, and has no effect # when using neutron for networking. # # Possible values: # # * Any integer, zero or greater. # # Related options: # # * ``use_neutron`` # (integer value) # Minimum value: 0 # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #fixed_ip_disassociate_timeout = 600 # DEPRECATED: # This option determines how many times nova-network will attempt to create a # unique MAC address before giving up and raising a # `VirtualInterfaceMacAddressException` error. # # Possible values: # # * Any positive integer. The default is 5. # # Related options: # # * ``use_neutron`` # (integer value) # Minimum value: 1 # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #create_unique_mac_address_attempts = 5 # DEPRECATED: # Determines whether unused gateway devices, both VLAN and bridge, are deleted # if # the network is in nova-network VLAN mode and is multi-hosted. # # Related options: # # * ``use_neutron`` # * ``vpn_ip`` # * ``fake_network`` # (boolean value) # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #teardown_unused_network_gateway = false # DEPRECATED: # When this option is True, a call is made to release the DHCP for the instance # when that instance is terminated. # # Related options: # # * ``use_neutron`` # (boolean value) # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #force_dhcp_release = true # DEPRECATED: # When this option is True, whenever a DNS entry must be updated, a fanout cast # message is sent to all network hosts to update their DNS entries in multi-host # mode. # # Related options: # # * ``use_neutron`` # (boolean value) # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #update_dns_entries = false # DEPRECATED: # This option determines the time, in seconds, to wait between refreshing DNS # entries for the network. # # Possible values: # # * A positive integer # * -1 to disable updates # # Related options: # # * ``use_neutron`` # (integer value) # Minimum value: -1 # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #dns_update_periodic_interval = -1 # DEPRECATED: # This option allows you to specify the domain for the DHCP server. # # Possible values: # # * Any string that is a valid domain name. # # Related options: # # * ``use_neutron`` # (string value) # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #dhcp_domain = novalocal # DEPRECATED: # This option allows you to specify the L3 management library to be used. # # Possible values: # # * Any dot-separated string that represents the import path to an L3 networking # library. # # Related options: # # * ``use_neutron`` # (string value) # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #l3_lib = nova.network.l3.LinuxNetL3 # DEPRECATED: # THIS VALUE SHOULD BE SET WHEN CREATING THE NETWORK. # # If True in multi_host mode, all compute hosts share the same dhcp address. The # same IP address used for DHCP will be added on each nova-network node which is # only visible to the VMs on the same host. # # The use of this configuration has been deprecated and may be removed in any # release after Mitaka. It is recommended that instead of relying on this # option, # an explicit value should be passed to 'create_networks()' as a keyword # argument # with the name 'share_address'. # (boolean value) # This option is deprecated for removal since 2014.2. # Its value may be silently ignored in the future. #share_dhcp_address = false # DEPRECATED: # URL for LDAP server which will store DNS entries # # Possible values: # # * A valid LDAP URL representing the server # (uri value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #ldap_dns_url = ldap://ldap.example.com:389 # DEPRECATED: Bind user for LDAP server (string value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #ldap_dns_user = uid=admin,ou=people,dc=example,dc=org # DEPRECATED: Bind user's password for LDAP server (string value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #ldap_dns_password = password # DEPRECATED: # Hostmaster for LDAP DNS driver Statement of Authority # # Possible values: # # * Any valid string representing LDAP DNS hostmaster. # (string value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #ldap_dns_soa_hostmaster = hostmaster at example.org # DEPRECATED: # DNS Servers for LDAP DNS driver # # Possible values: # # * A valid URL representing a DNS server # (multi valued) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #ldap_dns_servers = dns.example.org # DEPRECATED: # Base distinguished name for the LDAP search query # # This option helps to decide where to look up the host in LDAP. # (string value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #ldap_dns_base_dn = ou=hosts,dc=example,dc=org # DEPRECATED: # Refresh interval (in seconds) for LDAP DNS driver Start of Authority # # Time interval, a secondary/slave DNS server waits before requesting for # primary DNS server's current SOA record. If the records are different, # secondary DNS server will request a zone transfer from primary. # # NOTE: Lower values would cause more traffic. # (integer value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #ldap_dns_soa_refresh = 1800 # DEPRECATED: # Retry interval (in seconds) for LDAP DNS driver Start of Authority # # Time interval, a secondary/slave DNS server should wait, if an # attempt to transfer zone failed during the previous refresh interval. # (integer value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #ldap_dns_soa_retry = 3600 # DEPRECATED: # Expiry interval (in seconds) for LDAP DNS driver Start of Authority # # Time interval, a secondary/slave DNS server holds the information # before it is no longer considered authoritative. # (integer value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #ldap_dns_soa_expiry = 86400 # DEPRECATED: # Minimum interval (in seconds) for LDAP DNS driver Start of Authority # # It is Minimum time-to-live applies for all resource records in the # zone file. This value is supplied to other servers how long they # should keep the data in cache. # (integer value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #ldap_dns_soa_minimum = 7200 # DEPRECATED: # Default value for multi_host in networks. # # nova-network service can operate in a multi-host or single-host mode. # In multi-host mode each compute node runs a copy of nova-network and the # instances on that compute node use the compute node as a gateway to the # Internet. Where as in single-host mode, a central server runs the nova-network # service. All compute nodes forward traffic from the instances to the # cloud controller which then forwards traffic to the Internet. # # If this options is set to true, some rpc network calls will be sent directly # to host. # # Note that this option is only used when using nova-network instead of # Neutron in your deployment. # # Related options: # # * ``use_neutron`` # (boolean value) # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #multi_host = false # DEPRECATED: # Driver to use for network creation. # # Network driver initializes (creates bridges and so on) only when the # first VM lands on a host node. All network managers configure the # network using network drivers. The driver is not tied to any particular # network manager. # # The default Linux driver implements vlans, bridges, and iptables rules # using linux utilities. # # Note that this option is only used when using nova-network instead # of Neutron in your deployment. # # Related options: # # * ``use_neutron`` # (string value) # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #network_driver = nova.network.linux_net # DEPRECATED: # Firewall driver to use with ``nova-network`` service. # # This option only applies when using the ``nova-network`` service. When using # another networking services, such as Neutron, this should be to set to the # ``nova.virt.firewall.NoopFirewallDriver``. # # Possible values: # # * ``nova.virt.firewall.IptablesFirewallDriver`` # * ``nova.virt.firewall.NoopFirewallDriver`` # * ``nova.virt.libvirt.firewall.IptablesFirewallDriver`` # * [...] # # Related options: # # * ``use_neutron``: This must be set to ``False`` to enable ``nova-network`` # networking # (string value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #firewall_driver = nova.virt.firewall.NoopFirewallDriver # DEPRECATED: # Determine whether to allow network traffic from same network. # # When set to true, hosts on the same subnet are not filtered and are allowed # to pass all types of traffic between them. On a flat network, this allows # all instances from all projects unfiltered communication. With VLAN # networking, this allows access between instances within the same project. # # This option only applies when using the ``nova-network`` service. When using # another networking services, such as Neutron, security groups or other # approaches should be used. # # Possible values: # # * True: Network traffic should be allowed pass between all instances on the # same network, regardless of their tenant and security policies # * False: Network traffic should not be allowed pass between instances unless # it is unblocked in a security group # # Related options: # # * ``use_neutron``: This must be set to ``False`` to enable ``nova-network`` # networking # * ``firewall_driver``: This must be set to # ``nova.virt.libvirt.firewall.IptablesFirewallDriver`` to ensure the # libvirt firewall driver is enabled. # (boolean value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #allow_same_net_traffic = true # DEPRECATED: # Default pool for floating IPs. # # This option specifies the default floating IP pool for allocating floating # IPs. # # While allocating a floating ip, users can optionally pass in the name of the # pool they want to allocate from, otherwise it will be pulled from the # default pool. # # If this option is not set, then 'nova' is used as default floating pool. # # Possible values: # # * Any string representing a floating IP pool name # (string value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # This option was used for two purposes: to set the floating IP pool name for # nova-network and to do the same for neutron. nova-network is deprecated, as # are # any related configuration options. Users of neutron, meanwhile, should use the # 'default_floating_pool' option in the '[neutron]' group. #default_floating_pool = nova # DEPRECATED: # Autoassigning floating IP to VM # # When set to True, floating IP is auto allocated and associated # to the VM upon creation. # # Related options: # # * use_neutron: this options only works with nova-network. # (boolean value) # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #auto_assign_floating_ip = false # DEPRECATED: # Full class name for the DNS Manager for floating IPs. # # This option specifies the class of the driver that provides functionality # to manage DNS entries associated with floating IPs. # # When a user adds a DNS entry for a specified domain to a floating IP, # nova will add a DNS entry using the specified floating DNS driver. # When a floating IP is deallocated, its DNS entry will automatically be # deleted. # # Possible values: # # * Full Python path to the class to be used # # Related options: # # * use_neutron: this options only works with nova-network. # (string value) # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #floating_ip_dns_manager = nova.network.noop_dns_driver.NoopDNSDriver # DEPRECATED: # Full class name for the DNS Manager for instance IPs. # # This option specifies the class of the driver that provides functionality # to manage DNS entries for instances. # # On instance creation, nova will add DNS entries for the instance name and # id, using the specified instance DNS driver and domain. On instance deletion, # nova will remove the DNS entries. # # Possible values: # # * Full Python path to the class to be used # # Related options: # # * use_neutron: this options only works with nova-network. # (string value) # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #instance_dns_manager = nova.network.noop_dns_driver.NoopDNSDriver # DEPRECATED: # If specified, Nova checks if the availability_zone of every instance matches # what the database says the availability_zone should be for the specified # dns_domain. # # Related options: # # * use_neutron: this options only works with nova-network. # (string value) # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #instance_dns_domain = # DEPRECATED: # Assign IPv6 and IPv4 addresses when creating instances. # # Related options: # # * use_neutron: this only works with nova-network. # (boolean value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #use_ipv6 = false # DEPRECATED: # Abstracts out IPv6 address generation to pluggable backends. # # nova-network can be put into dual-stack mode, so that it uses # both IPv4 and IPv6 addresses. In dual-stack mode, by default, instances # acquire IPv6 global unicast addresses with the help of stateless address # auto-configuration mechanism. # # Related options: # # * use_neutron: this option only works with nova-network. # * use_ipv6: this option only works if ipv6 is enabled for nova-network. # (string value) # Possible values: # rfc2462 - # account_identifier - # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #ipv6_backend = rfc2462 # DEPRECATED: # This option is used to enable or disable quota checking for tenant networks. # # Related options: # # * quota_networks # (boolean value) # This option is deprecated for removal since 14.0.0. # Its value may be silently ignored in the future. # Reason: # CRUD operations on tenant networks are only available when using nova-network # and nova-network is itself deprecated. #enable_network_quota = false # DEPRECATED: # This option controls the number of private networks that can be created per # project (or per tenant). # # Related options: # # * enable_network_quota # (integer value) # Minimum value: 0 # This option is deprecated for removal since 14.0.0. # Its value may be silently ignored in the future. # Reason: # CRUD operations on tenant networks are only available when using nova-network # and nova-network is itself deprecated. #quota_networks = 3 # # Filename that will be used for storing websocket frames received # and sent by a proxy service (like VNC, spice, serial) running on this host. # If this is not set, no recording will be done. # (string value) #record = # Run as a background process. (boolean value) #daemon = false # Disallow non-encrypted connections. (boolean value) #ssl_only = false # Set to True if source host is addressed with IPv6. (boolean value) #source_is_ipv6 = false # Path to SSL certificate file. (string value) #cert = self.pem # SSL key file (if separate from cert). (string value) #key = # # Path to directory with content which will be served by a web server. # (string value) #web = /usr/share/spice-html5 # # The directory where the Nova python modules are installed. # # This directory is used to store template files for networking and remote # console access. It is also the default path for other config options which # need to persist Nova internal data. It is very unlikely that you need to # change this option from its default value. # # Possible values: # # * The full path to a directory. # # Related options: # # * ``state_path`` # (string value) #pybasedir = /build/nova-wLnpHi/nova-17.0.13 # # The directory where the Nova binaries are installed. # # This option is only relevant if the networking capabilities from Nova are # used (see services below). Nova's networking capabilities are targeted to # be fully replaced by Neutron in the future. It is very unlikely that you need # to change this option from its default value. # # Possible values: # # * The full path to a directory. # (string value) #bindir = /usr/local/bin # # The top-level directory for maintaining Nova's state. # # This directory is used to store Nova's internal state. It is used by a # variety of other config options which derive from this. In some scenarios # (for example migrations) it makes sense to use a storage location which is # shared between multiple compute hosts (for example via NFS). Unless the # option ``instances_path`` gets overwritten, this directory can grow very # large. # # Possible values: # # * The full path to a directory. Defaults to value provided in ``pybasedir``. # (string value) #state_path = $pybasedir # # Number of seconds indicating how frequently the state of services on a # given hypervisor is reported. Nova needs to know this to determine the # overall health of the deployment. # # Related Options: # # * service_down_time # report_interval should be less than service_down_time. If service_down_time # is less than report_interval, services will routinely be considered down, # because they report in too rarely. # (integer value) #report_interval = 10 # # Maximum time in seconds since last check-in for up service # # Each compute node periodically updates their database status based on the # specified report interval. If the compute node hasn't updated the status # for more than service_down_time, then the compute node is considered down. # # Related Options: # # * report_interval (service_down_time should not be less than report_interval) # (integer value) #service_down_time = 60 # # Enable periodic tasks. # # If set to true, this option allows services to periodically run tasks # on the manager. # # In case of running multiple schedulers or conductors you may want to run # periodic tasks on only one host - in this case disable this option for all # hosts but one. # (boolean value) #periodic_enable = true # # Number of seconds to randomly delay when starting the periodic task # scheduler to reduce stampeding. # # When compute workers are restarted in unison across a cluster, # they all end up running the periodic tasks at the same time # causing problems for the external services. To mitigate this # behavior, periodic_fuzzy_delay option allows you to introduce a # random initial delay when starting the periodic task scheduler. # # Possible Values: # # * Any positive integer (in seconds) # * 0 : disable the random delay # (integer value) # Minimum value: 0 #periodic_fuzzy_delay = 60 # List of APIs to be enabled by default. (list value) #enabled_apis = osapi_compute,metadata # # List of APIs with enabled SSL. # # Nova provides SSL support for the API servers. enabled_ssl_apis option # allows configuring the SSL support. # (list value) #enabled_ssl_apis = # # IP address on which the OpenStack API will listen. # # The OpenStack API service listens on this IP address for incoming # requests. # (string value) #osapi_compute_listen = 0.0.0.0 # # Port on which the OpenStack API will listen. # # The OpenStack API service listens on this port number for incoming # requests. # (port value) # Minimum value: 0 # Maximum value: 65535 #osapi_compute_listen_port = 8774 # # Number of workers for OpenStack API service. The default will be the number # of CPUs available. # # OpenStack API services can be configured to run as multi-process (workers). # This overcomes the problem of reduction in throughput when API request # concurrency increases. OpenStack API service will run in the specified # number of processes. # # Possible Values: # # * Any positive integer # * None (default value) # (integer value) # Minimum value: 1 #osapi_compute_workers = # # IP address on which the metadata API will listen. # # The metadata API service listens on this IP address for incoming # requests. # (string value) #metadata_listen = 0.0.0.0 # # Port on which the metadata API will listen. # # The metadata API service listens on this port number for incoming # requests. # (port value) # Minimum value: 0 # Maximum value: 65535 #metadata_listen_port = 8775 # # Number of workers for metadata service. If not specified the number of # available CPUs will be used. # # The metadata service can be configured to run as multi-process (workers). # This overcomes the problem of reduction in throughput when API request # concurrency increases. The metadata service will run in the specified # number of processes. # # Possible Values: # # * Any positive integer # * None (default value) # (integer value) # Minimum value: 1 #metadata_workers = # Full class name for the Manager for network (string value) # Possible values: # nova.network.manager.FlatManager - # nova.network.manager.FlatDHCPManager - # nova.network.manager.VlanManager - #network_manager = nova.network.manager.VlanManager # # This option specifies the driver to be used for the servicegroup service. # # ServiceGroup API in nova enables checking status of a compute node. When a # compute worker running the nova-compute daemon starts, it calls the join API # to join the compute group. Services like nova scheduler can query the # ServiceGroup API to check if a node is alive. Internally, the ServiceGroup # client driver automatically updates the compute worker status. There are # multiple backend implementations for this service: Database ServiceGroup # driver # and Memcache ServiceGroup driver. # # Possible Values: # # * db : Database ServiceGroup driver # * mc : Memcache ServiceGroup driver # # Related Options: # # * service_down_time (maximum time since last check-in for up service) # (string value) # Possible values: # db - # mc - #servicegroup_driver = db # # From oslo.log # # If set to true, the logging level will be set to DEBUG instead of the default # INFO level. (boolean value) # Note: This option can be changed without restarting. #debug = false # The name of a logging configuration file. This file is appended to any # existing logging configuration files. For details about logging configuration # files, see the Python logging module documentation. Note that when logging # configuration files are used then all logging configuration is set in the # configuration file and other logging configuration options are ignored (for # example, logging_context_format_string). (string value) # Note: This option can be changed without restarting. # Deprecated group/name - [DEFAULT]/log_config #log_config_append = # Defines the format string for %%(asctime)s in log records. Default: # %(default)s . This option is ignored if log_config_append is set. (string # value) #log_date_format = %Y-%m-%d %H:%M:%S # (Optional) Name of log file to send logging output to. If no default is set, # logging will go to stderr as defined by use_stderr. This option is ignored if # log_config_append is set. (string value) # Deprecated group/name - [DEFAULT]/logfile #log_file = # (Optional) The base directory used for relative log_file paths. This option # is ignored if log_config_append is set. (string value) # Deprecated group/name - [DEFAULT]/logdir #log_dir = # Uses logging handler designed to watch file system. When log file is moved or # removed this handler will open a new log file with specified path # instantaneously. It makes sense only if log_file option is specified and Linux # platform is used. This option is ignored if log_config_append is set. (boolean # value) #watch_log_file = false # Use syslog for logging. Existing syslog format is DEPRECATED and will be # changed later to honor RFC5424. This option is ignored if log_config_append is # set. (boolean value) #use_syslog = false # Enable journald for logging. If running in a systemd environment you may wish # to enable journal support. Doing so will use the journal native protocol which # includes structured metadata in addition to log messages.This option is # ignored if log_config_append is set. (boolean value) #use_journal = false # Syslog facility to receive log lines. This option is ignored if # log_config_append is set. (string value) #syslog_log_facility = LOG_USER # Use JSON formatting for logging. This option is ignored if log_config_append # is set. (boolean value) #use_json = false # Log output to standard error. This option is ignored if log_config_append is # set. (boolean value) #use_stderr = false # Format string to use for log messages with context. (string value) #logging_context_format_string = %(asctime)s.%(msecs)03d %(process)d %(levelname)s %(name)s [%(request_id)s %(user_identity)s] %(instance)s%(message)s # Format string to use for log messages when context is undefined. (string # value) #logging_default_format_string = %(asctime)s.%(msecs)03d %(process)d %(levelname)s %(name)s [-] %(instance)s%(message)s # Additional data to append to log message when logging level for the message is # DEBUG. (string value) #logging_debug_format_suffix = %(funcName)s %(pathname)s:%(lineno)d # Prefix each line of exception output with this format. (string value) #logging_exception_prefix = %(asctime)s.%(msecs)03d %(process)d ERROR %(name)s %(instance)s # Defines the format string for %(user_identity)s that is used in # logging_context_format_string. (string value) #logging_user_identity_format = %(user)s %(tenant)s %(domain)s %(user_domain)s %(project_domain)s # List of package logging levels in logger=LEVEL pairs. This option is ignored # if log_config_append is set. (list value) #default_log_levels = amqp=WARN,amqplib=WARN,boto=WARN,qpid=WARN,sqlalchemy=WARN,suds=INFO,oslo.messaging=INFO,oslo_messaging=INFO,iso8601=WARN,requests.packages.urllib3.connectionpool=WARN,urllib3.connectionpool=WARN,websocket=WARN,requests.packages.urllib3.util.retry=WARN,urllib3.util.retry=WARN,keystonemiddleware=WARN,routes.middleware=WARN,stevedore=WARN,taskflow=WARN,keystoneauth=WARN,oslo.cache=INFO,dogpile.core.dogpile=INFO # Enables or disables publication of error events. (boolean value) #publish_errors = false # The format for an instance that is passed with the log message. (string value) #instance_format = "[instance: %(uuid)s] " # The format for an instance UUID that is passed with the log message. (string # value) #instance_uuid_format = "[instance: %(uuid)s] " # Interval, number of seconds, of log rate limiting. (integer value) #rate_limit_interval = 0 # Maximum number of logged messages per rate_limit_interval. (integer value) #rate_limit_burst = 0 # Log level name used by rate limiting: CRITICAL, ERROR, INFO, WARNING, DEBUG or # empty string. Logs with level greater or equal to rate_limit_except_level are # not filtered. An empty string means that all levels are filtered. (string # value) #rate_limit_except_level = CRITICAL # Enables or disables fatal status of deprecations. (boolean value) #fatal_deprecations = false # # From oslo.messaging # # Size of RPC connection pool. (integer value) #rpc_conn_pool_size = 30 # The pool size limit for connections expiration policy (integer value) #conn_pool_min_size = 2 # The time-to-live in sec of idle connections in the pool (integer value) #conn_pool_ttl = 1200 # ZeroMQ bind address. Should be a wildcard (*), an ethernet interface, or IP. # The "host" option should point or resolve to this address. (string value) #rpc_zmq_bind_address = * # MatchMaker driver. (string value) # Possible values: # redis - # sentinel - # dummy - #rpc_zmq_matchmaker = redis # Number of ZeroMQ contexts, defaults to 1. (integer value) #rpc_zmq_contexts = 1 # Maximum number of ingress messages to locally buffer per topic. Default is # unlimited. (integer value) #rpc_zmq_topic_backlog = # Directory for holding IPC sockets. (string value) #rpc_zmq_ipc_dir = /var/run/openstack # Name of this node. Must be a valid hostname, FQDN, or IP address. Must match # "host" option, if running Nova. (string value) #rpc_zmq_host = localhost # Number of seconds to wait before all pending messages will be sent after # closing a socket. The default value of -1 specifies an infinite linger period. # The value of 0 specifies no linger period. Pending messages shall be discarded # immediately when the socket is closed. Positive values specify an upper bound # for the linger period. (integer value) # Deprecated group/name - [DEFAULT]/rpc_cast_timeout #zmq_linger = -1 # The default number of seconds that poll should wait. Poll raises timeout # exception when timeout expired. (integer value) #rpc_poll_timeout = 1 # Expiration timeout in seconds of a name service record about existing target ( # < 0 means no timeout). (integer value) #zmq_target_expire = 300 # Update period in seconds of a name service record about existing target. # (integer value) #zmq_target_update = 180 # Use PUB/SUB pattern for fanout methods. PUB/SUB always uses proxy. (boolean # value) #use_pub_sub = false # Use ROUTER remote proxy. (boolean value) #use_router_proxy = false # This option makes direct connections dynamic or static. It makes sense only # with use_router_proxy=False which means to use direct connections for direct # message types (ignored otherwise). (boolean value) #use_dynamic_connections = false # How many additional connections to a host will be made for failover reasons. # This option is actual only in dynamic connections mode. (integer value) #zmq_failover_connections = 2 # Minimal port number for random ports range. (port value) # Minimum value: 0 # Maximum value: 65535 #rpc_zmq_min_port = 49153 # Maximal port number for random ports range. (integer value) # Minimum value: 1 # Maximum value: 65536 #rpc_zmq_max_port = 65536 # Number of retries to find free port number before fail with ZMQBindError. # (integer value) #rpc_zmq_bind_port_retries = 100 # Default serialization mechanism for serializing/deserializing # outgoing/incoming messages (string value) # Possible values: # json - # msgpack - #rpc_zmq_serialization = json # This option configures round-robin mode in zmq socket. True means not keeping # a queue when server side disconnects. False means to keep queue and messages # even if server is disconnected, when the server appears we send all # accumulated messages to it. (boolean value) #zmq_immediate = true # Enable/disable TCP keepalive (KA) mechanism. The default value of -1 (or any # other negative value) means to skip any overrides and leave it to OS default; # 0 and 1 (or any other positive value) mean to disable and enable the option # respectively. (integer value) #zmq_tcp_keepalive = -1 # The duration between two keepalive transmissions in idle condition. The unit # is platform dependent, for example, seconds in Linux, milliseconds in Windows # etc. The default value of -1 (or any other negative value and 0) means to skip # any overrides and leave it to OS default. (integer value) #zmq_tcp_keepalive_idle = -1 # The number of retransmissions to be carried out before declaring that remote # end is not available. The default value of -1 (or any other negative value and # 0) means to skip any overrides and leave it to OS default. (integer value) #zmq_tcp_keepalive_cnt = -1 # The duration between two successive keepalive retransmissions, if # acknowledgement to the previous keepalive transmission is not received. The # unit is platform dependent, for example, seconds in Linux, milliseconds in # Windows etc. The default value of -1 (or any other negative value and 0) means # to skip any overrides and leave it to OS default. (integer value) #zmq_tcp_keepalive_intvl = -1 # Maximum number of (green) threads to work concurrently. (integer value) #rpc_thread_pool_size = 100 # Expiration timeout in seconds of a sent/received message after which it is not # tracked anymore by a client/server. (integer value) #rpc_message_ttl = 300 # Wait for message acknowledgements from receivers. This mechanism works only # via proxy without PUB/SUB. (boolean value) #rpc_use_acks = false # Number of seconds to wait for an ack from a cast/call. After each retry # attempt this timeout is multiplied by some specified multiplier. (integer # value) #rpc_ack_timeout_base = 15 # Number to multiply base ack timeout by after each retry attempt. (integer # value) #rpc_ack_timeout_multiplier = 2 # Default number of message sending attempts in case of any problems occurred: # positive value N means at most N retries, 0 means no retries, None or -1 (or # any other negative values) mean to retry forever. This option is used only if # acknowledgments are enabled. (integer value) #rpc_retry_attempts = 3 # List of publisher hosts SubConsumer can subscribe on. This option has higher # priority then the default publishers list taken from the matchmaker. (list # value) #subscribe_on = # Size of executor thread pool when executor is threading or eventlet. (integer # value) # Deprecated group/name - [DEFAULT]/rpc_thread_pool_size #executor_thread_pool_size = 64 # Seconds to wait for a response from a call. (integer value) #rpc_response_timeout = 60 # The network address and optional user credentials for connecting to the # messaging backend, in URL format. The expected format is: # # driver://[user:pass@]host:port[,[userN:passN@]hostN:portN]/virtual_host?query # # Example: rabbit://rabbitmq:password at 127.0.0.1:5672// # # For full details on the fields in the URL see the documentation of # oslo_messaging.TransportURL at # https://docs.openstack.org/oslo.messaging/latest/reference/transport.html # (string value) #transport_url = # DEPRECATED: The messaging driver to use, defaults to rabbit. Other drivers # include amqp and zmq. (string value) # This option is deprecated for removal. # Its value may be silently ignored in the future. # Reason: Replaced by [DEFAULT]/transport_url #rpc_backend = rabbit # The default exchange under which topics are scoped. May be overridden by an # exchange name specified in the transport_url option. (string value) #control_exchange = openstack # # From oslo.service.periodic_task # # Some periodic tasks can be run in a separate process. Should we run them here? # (boolean value) #run_external_periodic_tasks = true # # From oslo.service.service # # Enable eventlet backdoor. Acceptable values are 0, , and :, # where 0 results in listening on a random tcp port number; results in # listening on the specified port number (and not enabling backdoor if that port # is in use); and : results in listening on the smallest unused port # number within the specified range of port numbers. The chosen port is # displayed in the service's log file. (string value) #backdoor_port = # Enable eventlet backdoor, using the provided path as a unix socket that can # receive connections. This option is mutually exclusive with 'backdoor_port' in # that only one should be provided. If both are provided then the existence of # this option overrides the usage of that option. (string value) #backdoor_socket = # Enables or disables logging values of all registered options when starting a # service (at DEBUG level). (boolean value) #log_options = true # Specify a timeout after which a gracefully shutdown server will exit. Zero # value means endless wait. (integer value) #graceful_shutdown_timeout = 60 [api] # # Options under this group are used to define Nova API. #pavlos auth_strategy = keystone # # From nova.conf # # # This determines the strategy to use for authentication: keystone or noauth2. # 'noauth2' is designed for testing only, as it does no actual credential # checking. 'noauth2' provides administrative credentials only if 'admin' is # specified as the username. # (string value) # Possible values: # keystone - # noauth2 - #auth_strategy = keystone # # When True, the 'X-Forwarded-For' header is treated as the canonical remote # address. When False (the default), the 'remote_address' header is used. # # You should only enable this if you have an HTML sanitizing proxy. # (boolean value) #use_forwarded_for = false # # When gathering the existing metadata for a config drive, the EC2-style # metadata is returned for all versions that don't appear in this option. # As of the Liberty release, the available versions are: # # * 1.0 # * 2007-01-19 # * 2007-03-01 # * 2007-08-29 # * 2007-10-10 # * 2007-12-15 # * 2008-02-01 # * 2008-09-01 # * 2009-04-04 # # The option is in the format of a single string, with each version separated # by a space. # # Possible values: # # * Any string that represents zero or more versions, separated by spaces. # (string value) #config_drive_skip_versions = 1.0 2007-01-19 2007-03-01 2007-08-29 2007-10-10 2007-12-15 2008-02-01 2008-09-01 # # A list of vendordata providers. # # vendordata providers are how deployers can provide metadata via configdrive # and metadata that is specific to their deployment. There are currently two # supported providers: StaticJSON and DynamicJSON. # # StaticJSON reads a JSON file configured by the flag vendordata_jsonfile_path # and places the JSON from that file into vendor_data.json and # vendor_data2.json. # # DynamicJSON is configured via the vendordata_dynamic_targets flag, which is # documented separately. For each of the endpoints specified in that flag, a # section is added to the vendor_data2.json. # # For more information on the requirements for implementing a vendordata # dynamic endpoint, please see the vendordata.rst file in the nova developer # reference. # # Possible values: # # * A list of vendordata providers, with StaticJSON and DynamicJSON being # current options. # # Related options: # # * vendordata_dynamic_targets # * vendordata_dynamic_ssl_certfile # * vendordata_dynamic_connect_timeout # * vendordata_dynamic_read_timeout # * vendordata_dynamic_failure_fatal # (list value) #vendordata_providers = StaticJSON # # A list of targets for the dynamic vendordata provider. These targets are of # the form @. # # The dynamic vendordata provider collects metadata by contacting external REST # services and querying them for information about the instance. This behaviour # is documented in the vendordata.rst file in the nova developer reference. # (list value) #vendordata_dynamic_targets = # # Path to an optional certificate file or CA bundle to verify dynamic # vendordata REST services ssl certificates against. # # Possible values: # # * An empty string, or a path to a valid certificate file # # Related options: # # * vendordata_providers # * vendordata_dynamic_targets # * vendordata_dynamic_connect_timeout # * vendordata_dynamic_read_timeout # * vendordata_dynamic_failure_fatal # (string value) #vendordata_dynamic_ssl_certfile = # # Maximum wait time for an external REST service to connect. # # Possible values: # # * Any integer with a value greater than three (the TCP packet retransmission # timeout). Note that instance start may be blocked during this wait time, # so this value should be kept small. # # Related options: # # * vendordata_providers # * vendordata_dynamic_targets # * vendordata_dynamic_ssl_certfile # * vendordata_dynamic_read_timeout # * vendordata_dynamic_failure_fatal # (integer value) # Minimum value: 3 #vendordata_dynamic_connect_timeout = 5 # # Maximum wait time for an external REST service to return data once connected. # # Possible values: # # * Any integer. Note that instance start is blocked during this wait time, # so this value should be kept small. # # Related options: # # * vendordata_providers # * vendordata_dynamic_targets # * vendordata_dynamic_ssl_certfile # * vendordata_dynamic_connect_timeout # * vendordata_dynamic_failure_fatal # (integer value) # Minimum value: 0 #vendordata_dynamic_read_timeout = 5 # # Should failures to fetch dynamic vendordata be fatal to instance boot? # # Related options: # # * vendordata_providers # * vendordata_dynamic_targets # * vendordata_dynamic_ssl_certfile # * vendordata_dynamic_connect_timeout # * vendordata_dynamic_read_timeout # (boolean value) #vendordata_dynamic_failure_fatal = false # # This option is the time (in seconds) to cache metadata. When set to 0, # metadata caching is disabled entirely; this is generally not recommended for # performance reasons. Increasing this setting should improve response times # of the metadata API when under heavy load. Higher values may increase memory # usage, and result in longer times for host metadata changes to take effect. # (integer value) # Minimum value: 0 #metadata_cache_expiration = 15 # # Cloud providers may store custom data in vendor data file that will then be # available to the instances via the metadata service, and to the rendering of # config-drive. The default class for this, JsonFileVendorData, loads this # information from a JSON file, whose path is configured by this option. If # there is no path set by this option, the class returns an empty dictionary. # # Possible values: # # * Any string representing the path to the data file, or an empty string # (default). # (string value) #vendordata_jsonfile_path = # # As a query can potentially return many thousands of items, you can limit the # maximum number of items in a single response by setting this option. # (integer value) # Minimum value: 0 # Deprecated group/name - [DEFAULT]/osapi_max_limit #max_limit = 1000 # # This string is prepended to the normal URL that is returned in links to the # OpenStack Compute API. If it is empty (the default), the URLs are returned # unchanged. # # Possible values: # # * Any string, including an empty string (the default). # (string value) # Deprecated group/name - [DEFAULT]/osapi_compute_link_prefix #compute_link_prefix = # # This string is prepended to the normal URL that is returned in links to # Glance resources. If it is empty (the default), the URLs are returned # unchanged. # # Possible values: # # * Any string, including an empty string (the default). # (string value) # Deprecated group/name - [DEFAULT]/osapi_glance_link_prefix #glance_link_prefix = # DEPRECATED: # Operators can turn off the ability for a user to take snapshots of their # instances by setting this option to False. When disabled, any attempt to # take a snapshot will result in a HTTP 400 response ("Bad Request"). # (boolean value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: This option disables the createImage server action API in a non- # discoverable way and is thus a barrier to interoperability. Also, it is not # used for other APIs that create snapshots like shelve or createBackup. # Disabling snapshots should be done via policy if so desired. #allow_instance_snapshots = true # DEPRECATED: # This option is a list of all instance states for which network address # information should not be returned from the API. # # Possible values: # # A list of strings, where each string is a valid VM state, as defined in # nova/compute/vm_states.py. As of the Newton release, they are: # # * "active" # * "building" # * "paused" # * "suspended" # * "stopped" # * "rescued" # * "resized" # * "soft-delete" # * "deleted" # * "error" # * "shelved" # * "shelved_offloaded" # (list value) # Deprecated group/name - [DEFAULT]/osapi_hide_server_address_states # This option is deprecated for removal since 17.0.0. # Its value may be silently ignored in the future. # Reason: This option hide the server address in server representation for # configured server states. Which makes GET server API controlled by this config # options. Due to this config options, user would not be able to discover the # API behavior on different clouds which leads to the interop issue. #hide_server_address_states = building # The full path to the fping binary. (string value) #fping_path = /usr/sbin/fping # # When True, the TenantNetworkController will query the Neutron API to get the # default networks to use. # # Related options: # # * neutron_default_tenant_id # (boolean value) #use_neutron_default_nets = false # # Tenant ID for getting the default network from Neutron API (also referred in # some places as the 'project ID') to use. # # Related options: # # * use_neutron_default_nets # (string value) #neutron_default_tenant_id = default # # Enables returning of the instance password by the relevant server API calls # such as create, rebuild, evacuate, or rescue. If the hypervisor does not # support password injection, then the password returned will not be correct, # so if your hypervisor does not support password injection, set this to False. # (boolean value) #enable_instance_password = true [api_database] connection = sqlite:////var/lib/nova/nova_api.sqlite # # The *Nova API Database* is a separate database which is used for information # which is used across *cells*. This database is mandatory since the Mitaka # release (13.0.0). # # From nova.conf # # The SQLAlchemy connection string to use to connect to the database. (string # value) #connection = # If True, SQLite uses synchronous mode. (boolean value) #sqlite_synchronous = true # The SQLAlchemy connection string to use to connect to the slave database. # (string value) #slave_connection = # The SQL mode to be used for MySQL sessions. This option, including the # default, overrides any server-set SQL mode. To use whatever SQL mode is set by # the server configuration, set this to no value. Example: mysql_sql_mode= # (string value) #mysql_sql_mode = TRADITIONAL # Connections which have been present in the connection pool longer than this # number of seconds will be replaced with a new one the next time they are # checked out from the pool. (integer value) # Deprecated group/name - [api_database]/idle_timeout #connection_recycle_time = 3600 # Maximum number of SQL connections to keep open in a pool. Setting a value of 0 # indicates no limit. (integer value) #max_pool_size = # Maximum number of database connection retries during startup. Set to -1 to # specify an infinite retry count. (integer value) #max_retries = 10 # Interval between retries of opening a SQL connection. (integer value) #retry_interval = 10 # If set, use this value for max_overflow with SQLAlchemy. (integer value) #max_overflow = # Verbosity of SQL debugging information: 0=None, 100=Everything. (integer # value) #connection_debug = 0 # Add Python stack traces to SQL as comment strings. (boolean value) #connection_trace = false # If set, use this value for pool_timeout with SQLAlchemy. (integer value) #pool_timeout = [barbican] # # From nova.conf # # Use this endpoint to connect to Barbican, for example: # "http://localhost:9311/" (string value) #barbican_endpoint = # Version of the Barbican API, for example: "v1" (string value) #barbican_api_version = # Use this endpoint to connect to Keystone (string value) # Deprecated group/name - [key_manager]/auth_url #auth_endpoint = http://localhost/identity/v3 # Number of seconds to wait before retrying poll for key creation completion # (integer value) #retry_delay = 1 # Number of times to retry poll for key creation completion (integer value) #number_of_retries = 60 # Specifies if insecure TLS (https) requests. If False, the server's certificate # will not be validated (boolean value) #verify_ssl = true [cache] # # From nova.conf # # Prefix for building the configuration dictionary for the cache region. This # should not need to be changed unless there is another dogpile.cache region # with the same configuration name. (string value) #config_prefix = cache.oslo # Default TTL, in seconds, for any cached item in the dogpile.cache region. This # applies to any cached method that doesn't have an explicit cache expiration # time defined for it. (integer value) #expiration_time = 600 # Cache backend module. For eventlet-based or environments with hundreds of # threaded servers, Memcache with pooling (oslo_cache.memcache_pool) is # recommended. For environments with less than 100 threaded servers, Memcached # (dogpile.cache.memcached) or Redis (dogpile.cache.redis) is recommended. Test # environments with a single instance of the server can use the # dogpile.cache.memory backend. (string value) # Possible values: # oslo_cache.memcache_pool - # oslo_cache.dict - # oslo_cache.mongo - # oslo_cache.etcd3gw - # dogpile.cache.memcached - # dogpile.cache.pylibmc - # dogpile.cache.bmemcached - # dogpile.cache.dbm - # dogpile.cache.redis - # dogpile.cache.memory - # dogpile.cache.memory_pickle - # dogpile.cache.null - #backend = dogpile.cache.null # Arguments supplied to the backend module. Specify this option once per # argument to be passed to the dogpile.cache backend. Example format: # ":". (multi valued) #backend_argument = # Proxy classes to import that will affect the way the dogpile.cache backend # functions. See the dogpile.cache documentation on changing-backend-behavior. # (list value) #proxies = # Global toggle for caching. (boolean value) #enabled = false # Extra debugging from the cache backend (cache keys, get/set/delete/etc calls). # This is only really useful if you need to see the specific cache-backend # get/set/delete calls with the keys/values. Typically this should be left set # to false. (boolean value) #debug_cache_backend = false # Memcache servers in the format of "host:port". (dogpile.cache.memcache and # oslo_cache.memcache_pool backends only). (list value) #memcache_servers = localhost:11211 # Number of seconds memcached server is considered dead before it is tried # again. (dogpile.cache.memcache and oslo_cache.memcache_pool backends only). # (integer value) #memcache_dead_retry = 300 # Timeout in seconds for every call to a server. (dogpile.cache.memcache and # oslo_cache.memcache_pool backends only). (integer value) #memcache_socket_timeout = 3 # Max total number of open connections to every memcached server. # (oslo_cache.memcache_pool backend only). (integer value) #memcache_pool_maxsize = 10 # Number of seconds a connection to memcached is held unused in the pool before # it is closed. (oslo_cache.memcache_pool backend only). (integer value) #memcache_pool_unused_timeout = 60 # Number of seconds that an operation will wait to get a memcache client # connection. (integer value) #memcache_pool_connection_get_timeout = 10 [cells] enable = False # # DEPRECATED: Cells options allow you to use cells v1 functionality in an # OpenStack deployment. # # Note that the options in this group are only for cells v1 functionality, which # is considered experimental and not recommended for new deployments. Cells v1 # is being replaced with cells v2, which starting in the 15.0.0 Ocata release is # required and all Nova deployments will be at least a cells v2 cell of one. # # # From nova.conf # # DEPRECATED: # Enable cell v1 functionality. # # Note that cells v1 is considered experimental and not recommended for new # Nova deployments. Cells v1 is being replaced by cells v2 which starting in # the 15.0.0 Ocata release, all Nova deployments are at least a cells v2 cell # of one. Setting this option, or any other options in the [cells] group, is # not required for cells v2. # # When this functionality is enabled, it lets you to scale an OpenStack # Compute cloud in a more distributed fashion without having to use # complicated technologies like database and message queue clustering. # Cells are configured as a tree. The top-level cell should have a host # that runs a nova-api service, but no nova-compute services. Each # child cell should run all of the typical nova-* services in a regular # Compute cloud except for nova-api. You can think of cells as a normal # Compute deployment in that each cell has its own database server and # message queue broker. # # Related options: # # * name: A unique cell name must be given when this functionality # is enabled. # * cell_type: Cell type should be defined for all cells. # (boolean value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: Cells v1 is being replaced with Cells v2. #enable = false # DEPRECATED: # Name of the current cell. # # This value must be unique for each cell. Name of a cell is used as # its id, leaving this option unset or setting the same name for # two or more cells may cause unexpected behaviour. # # Related options: # # * enabled: This option is meaningful only when cells service # is enabled # (string value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: Cells v1 is being replaced with Cells v2. #name = nova # DEPRECATED: # Cell capabilities. # # List of arbitrary key=value pairs defining capabilities of the # current cell to be sent to the parent cells. These capabilities # are intended to be used in cells scheduler filters/weighers. # # Possible values: # # * key=value pairs list for example; # ``hypervisor=xenserver;kvm,os=linux;windows`` # (list value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: Cells v1 is being replaced with Cells v2. #capabilities = hypervisor=xenserver;kvm,os=linux;windows # DEPRECATED: # Call timeout. # # Cell messaging module waits for response(s) to be put into the # eventlet queue. This option defines the seconds waited for # response from a call to a cell. # # Possible values: # # * An integer, corresponding to the interval time in seconds. # (integer value) # Minimum value: 0 # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: Cells v1 is being replaced with Cells v2. #call_timeout = 60 # DEPRECATED: # Reserve percentage # # Percentage of cell capacity to hold in reserve, so the minimum # amount of free resource is considered to be; # # min_free = total * (reserve_percent / 100.0) # # This option affects both memory and disk utilization. # # The primary purpose of this reserve is to ensure some space is # available for users who want to resize their instance to be larger. # Note that currently once the capacity expands into this reserve # space this option is ignored. # # Possible values: # # * An integer or float, corresponding to the percentage of cell capacity to # be held in reserve. # (floating point value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: Cells v1 is being replaced with Cells v2. #reserve_percent = 10.0 # DEPRECATED: # Type of cell. # # When cells feature is enabled the hosts in the OpenStack Compute # cloud are partitioned into groups. Cells are configured as a tree. # The top-level cell's cell_type must be set to ``api``. All other # cells are defined as a ``compute cell`` by default. # # Related option: # # * quota_driver: Disable quota checking for the child cells. # (nova.quota.NoopQuotaDriver) # (string value) # Possible values: # api - # compute - # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: Cells v1 is being replaced with Cells v2. #cell_type = compute # DEPRECATED: # Mute child interval. # # Number of seconds after which a lack of capability and capacity # update the child cell is to be treated as a mute cell. Then the # child cell will be weighed as recommend highly that it be skipped. # # Possible values: # # * An integer, corresponding to the interval time in seconds. # (integer value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: Cells v1 is being replaced with Cells v2. #mute_child_interval = 300 # DEPRECATED: # Bandwidth update interval. # # Seconds between bandwidth usage cache updates for cells. # # Possible values: # # * An integer, corresponding to the interval time in seconds. # (integer value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: Cells v1 is being replaced with Cells v2. #bandwidth_update_interval = 600 # DEPRECATED: # Instance update sync database limit. # # Number of instances to pull from the database at one time for # a sync. If there are more instances to update the results will # be paged through. # # Possible values: # # * An integer, corresponding to a number of instances. # (integer value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: Cells v1 is being replaced with Cells v2. #instance_update_sync_database_limit = 100 # DEPRECATED: # Mute weight multiplier. # # Multiplier used to weigh mute children. Mute children cells are # recommended to be skipped so their weight is multiplied by this # negative value. # # Possible values: # # * Negative numeric number # (floating point value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: Cells v1 is being replaced with Cells v2. #mute_weight_multiplier = -10000.0 # DEPRECATED: # Ram weight multiplier. # # Multiplier used for weighing ram. Negative numbers indicate that # Compute should stack VMs on one host instead of spreading out new # VMs to more hosts in the cell. # # Possible values: # # * Numeric multiplier # (floating point value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: Cells v1 is being replaced with Cells v2. #ram_weight_multiplier = 10.0 # DEPRECATED: # Offset weight multiplier # # Multiplier used to weigh offset weigher. Cells with higher # weight_offsets in the DB will be preferred. The weight_offset # is a property of a cell stored in the database. It can be used # by a deployer to have scheduling decisions favor or disfavor # cells based on the setting. # # Possible values: # # * Numeric multiplier # (floating point value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: Cells v1 is being replaced with Cells v2. #offset_weight_multiplier = 1.0 # DEPRECATED: # Instance updated at threshold # # Number of seconds after an instance was updated or deleted to # continue to update cells. This option lets cells manager to only # attempt to sync instances that have been updated recently. # i.e., a threshold of 3600 means to only update instances that # have modified in the last hour. # # Possible values: # # * Threshold in seconds # # Related options: # # * This value is used with the ``instance_update_num_instances`` # value in a periodic task run. # (integer value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: Cells v1 is being replaced with Cells v2. #instance_updated_at_threshold = 3600 # DEPRECATED: # Instance update num instances # # On every run of the periodic task, nova cells manager will attempt to # sync instance_updated_at_threshold number of instances. When the # manager gets the list of instances, it shuffles them so that multiple # nova-cells services do not attempt to sync the same instances in # lockstep. # # Possible values: # # * Positive integer number # # Related options: # # * This value is used with the ``instance_updated_at_threshold`` # value in a periodic task run. # (integer value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: Cells v1 is being replaced with Cells v2. #instance_update_num_instances = 1 # DEPRECATED: # Maximum hop count # # When processing a targeted message, if the local cell is not the # target, a route is defined between neighbouring cells. And the # message is processed across the whole routing path. This option # defines the maximum hop counts until reaching the target. # # Possible values: # # * Positive integer value # (integer value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: Cells v1 is being replaced with Cells v2. #max_hop_count = 10 # DEPRECATED: # Cells scheduler. # # The class of the driver used by the cells scheduler. This should be # the full Python path to the class to be used. If nothing is specified # in this option, the CellsScheduler is used. # (string value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: Cells v1 is being replaced with Cells v2. #scheduler = nova.cells.scheduler.CellsScheduler # DEPRECATED: # RPC driver queue base. # # When sending a message to another cell by JSON-ifying the message # and making an RPC cast to 'process_message', a base queue is used. # This option defines the base queue name to be used when communicating # between cells. Various topics by message type will be appended to this. # # Possible values: # # * The base queue name to be used when communicating between cells. # (string value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: Cells v1 is being replaced with Cells v2. #rpc_driver_queue_base = cells.intercell # DEPRECATED: # Scheduler filter classes. # # Filter classes the cells scheduler should use. An entry of # "nova.cells.filters.all_filters" maps to all cells filters # included with nova. As of the Mitaka release the following # filter classes are available: # # Different cell filter: A scheduler hint of 'different_cell' # with a value of a full cell name may be specified to route # a build away from a particular cell. # # Image properties filter: Image metadata named # 'hypervisor_version_requires' with a version specification # may be specified to ensure the build goes to a cell which # has hypervisors of the required version. If either the version # requirement on the image or the hypervisor capability of the # cell is not present, this filter returns without filtering out # the cells. # # Target cell filter: A scheduler hint of 'target_cell' with a # value of a full cell name may be specified to route a build to # a particular cell. No error handling is done as there's no way # to know whether the full path is a valid. # # As an admin user, you can also add a filter that directs builds # to a particular cell. # # (list value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: Cells v1 is being replaced with Cells v2. #scheduler_filter_classes = nova.cells.filters.all_filters # DEPRECATED: # Scheduler weight classes. # # Weigher classes the cells scheduler should use. An entry of # "nova.cells.weights.all_weighers" maps to all cell weighers # included with nova. As of the Mitaka release the following # weight classes are available: # # mute_child: Downgrades the likelihood of child cells being # chosen for scheduling requests, which haven't sent capacity # or capability updates in a while. Options include # mute_weight_multiplier (multiplier for mute children; value # should be negative). # # ram_by_instance_type: Select cells with the most RAM capacity # for the instance type being requested. Because higher weights # win, Compute returns the number of available units for the # instance type requested. The ram_weight_multiplier option defaults # to 10.0 that adds to the weight by a factor of 10. Use a negative # number to stack VMs on one host instead of spreading out new VMs # to more hosts in the cell. # # weight_offset: Allows modifying the database to weight a particular # cell. The highest weight will be the first cell to be scheduled for # launching an instance. When the weight_offset of a cell is set to 0, # it is unlikely to be picked but it could be picked if other cells # have a lower weight, like if they're full. And when the weight_offset # is set to a very high value (for example, '999999999999999'), it is # likely to be picked if another cell do not have a higher weight. # (list value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: Cells v1 is being replaced with Cells v2. #scheduler_weight_classes = nova.cells.weights.all_weighers # DEPRECATED: # Scheduler retries. # # How many retries when no cells are available. Specifies how many # times the scheduler tries to launch a new instance when no cells # are available. # # Possible values: # # * Positive integer value # # Related options: # # * This value is used with the ``scheduler_retry_delay`` value # while retrying to find a suitable cell. # (integer value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: Cells v1 is being replaced with Cells v2. #scheduler_retries = 10 # DEPRECATED: # Scheduler retry delay. # # Specifies the delay (in seconds) between scheduling retries when no # cell can be found to place the new instance on. When the instance # could not be scheduled to a cell after ``scheduler_retries`` in # combination with ``scheduler_retry_delay``, then the scheduling # of the instance failed. # # Possible values: # # * Time in seconds. # # Related options: # # * This value is used with the ``scheduler_retries`` value # while retrying to find a suitable cell. # (integer value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: Cells v1 is being replaced with Cells v2. #scheduler_retry_delay = 2 # DEPRECATED: # DB check interval. # # Cell state manager updates cell status for all cells from the DB # only after this particular interval time is passed. Otherwise cached # status are used. If this value is 0 or negative all cell status are # updated from the DB whenever a state is needed. # # Possible values: # # * Interval time, in seconds. # # (integer value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: Cells v1 is being replaced with Cells v2. #db_check_interval = 60 # DEPRECATED: # Optional cells configuration. # # Configuration file from which to read cells configuration. If given, # overrides reading cells from the database. # # Cells store all inter-cell communication data, including user names # and passwords, in the database. Because the cells data is not updated # very frequently, use this option to specify a JSON file to store # cells data. With this configuration, the database is no longer # consulted when reloading the cells data. The file must have columns # present in the Cell model (excluding common database fields and the # id column). You must specify the queue connection information through # a transport_url field, instead of username, password, and so on. # # The transport_url has the following form: # rabbit://USERNAME:PASSWORD at HOSTNAME:PORT/VIRTUAL_HOST # # Possible values: # # The scheme can be either qpid or rabbit, the following sample shows # this optional configuration: # # { # "parent": { # "name": "parent", # "api_url": "http://api.example.com:8774", # "transport_url": "rabbit://rabbit.example.com", # "weight_offset": 0.0, # "weight_scale": 1.0, # "is_parent": true # }, # "cell1": { # "name": "cell1", # "api_url": "http://api.example.com:8774", # "transport_url": "rabbit://rabbit1.example.com", # "weight_offset": 0.0, # "weight_scale": 1.0, # "is_parent": false # }, # "cell2": { # "name": "cell2", # "api_url": "http://api.example.com:8774", # "transport_url": "rabbit://rabbit2.example.com", # "weight_offset": 0.0, # "weight_scale": 1.0, # "is_parent": false # } # } # # (string value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: Cells v1 is being replaced with Cells v2. #cells_config = [cinder] # # From nova.conf # # # Info to match when looking for cinder in the service catalog. # # Possible values: # # * Format is separated values of the form: # :: # # Note: Nova does not support the Cinder v2 API since the Nova 17.0.0 Queens # release. # # Related options: # # * endpoint_template - Setting this option will override catalog_info # (string value) #catalog_info = volumev3:cinderv3:publicURL # # If this option is set then it will override service catalog lookup with # this template for cinder endpoint # # Possible values: # # * URL for cinder endpoint API # e.g. http://localhost:8776/v3/%(project_id)s # # Note: Nova does not support the Cinder v2 API since the Nova 17.0.0 Queens # release. # # Related options: # # * catalog_info - If endpoint_template is not set, catalog_info will be used. # (string value) #endpoint_template = # # Region name of this node. This is used when picking the URL in the service # catalog. # # Possible values: # # * Any string representing region name # (string value) #os_region_name = # # Number of times cinderclient should retry on any failed http call. # 0 means connection is attempted only once. Setting it to any positive integer # means that on failure connection is retried that many times e.g. setting it # to 3 means total attempts to connect will be 4. # # Possible values: # # * Any integer value. 0 means connection is attempted only once # (integer value) # Minimum value: 0 #http_retries = 3 # # Allow attach between instance and volume in different availability zones. # # If False, volumes attached to an instance must be in the same availability # zone in Cinder as the instance availability zone in Nova. # This also means care should be taken when booting an instance from a volume # where source is not "volume" because Nova will attempt to create a volume # using # the same availability zone as what is assigned to the instance. # If that AZ is not in Cinder (or allow_availability_zone_fallback=False in # cinder.conf), the volume create request will fail and the instance will fail # the build request. # By default there is no availability zone restriction on volume attach. # (boolean value) #cross_az_attach = true # PEM encoded Certificate Authority to use when verifying HTTPs connections. # (string value) #cafile = # PEM encoded client certificate cert file (string value) #certfile = # PEM encoded client certificate key file (string value) #keyfile = # Verify HTTPS connections. (boolean value) #insecure = false # Timeout value for http requests (integer value) #timeout = # Authentication type to load (string value) # Deprecated group/name - [cinder]/auth_plugin #auth_type = # Config Section from which to load plugin specific options (string value) #auth_section = # Authentication URL (string value) #auth_url = # Scope for system operations (string value) #system_scope = # Domain ID to scope to (string value) #domain_id = # Domain name to scope to (string value) #domain_name = # Project ID to scope to (string value) #project_id = # Project name to scope to (string value) #project_name = # Domain ID containing project (string value) #project_domain_id = # Domain name containing project (string value) #project_domain_name = # Trust ID (string value) #trust_id = # Optional domain ID to use with v3 and v2 parameters. It will be used for both # the user and project domain in v3 and ignored in v2 authentication. (string # value) #default_domain_id = # Optional domain name to use with v3 API and v2 parameters. It will be used for # both the user and project domain in v3 and ignored in v2 authentication. # (string value) #default_domain_name = # User ID (string value) #user_id = # Username (string value) # Deprecated group/name - [cinder]/user_name #username = # User's domain id (string value) #user_domain_id = # User's domain name (string value) #user_domain_name = # User's password (string value) #password = # Tenant ID (string value) #tenant_id = # Tenant Name (string value) #tenant_name = [compute] # # From nova.conf # # # Enables reporting of build failures to the scheduler. # # Any nonzero value will enable sending build failure statistics to the # scheduler for use by the BuildFailureWeigher. # # Possible values: # # * Any positive integer enables reporting build failures. # * Zero to disable reporting build failures. # # Related options: # # * [filter_scheduler]/build_failure_weight_multiplier # # (integer value) #consecutive_build_service_disable_threshold = 10 # # Interval for updating nova-compute-side cache of the compute node resource # provider's aggregates and traits info. # # This option specifies the number of seconds between attempts to update a # provider's aggregates and traits information in the local cache of the compute # node. # # Possible values: # # * Any positive integer in seconds. # (integer value) # Minimum value: 1 #resource_provider_association_refresh = 300 # # Determine if the source compute host should wait for a ``network-vif-plugged`` # event from the (neutron) networking service before starting the actual # transfer # of the guest to the destination compute host. # # If you set this option the same on all of your compute hosts, which you should # do if you use the same networking backend universally, you do not have to # worry about this. # # Before starting the transfer of the guest, some setup occurs on the # destination # compute host, including plugging virtual interfaces. Depending on the # networking backend **on the destination host**, a ``network-vif-plugged`` # event may be triggered and then received on the source compute host and the # source compute can wait for that event to ensure networking is set up on the # destination host before starting the guest transfer in the hypervisor. # # By default, this is False for two reasons: # # 1. Backward compatibility: deployments should test this out and ensure it # works # for them before enabling it. # # 2. The compute service cannot reliably determine which types of virtual # interfaces (``port.binding:vif_type``) will send ``network-vif-plugged`` # events without an accompanying port ``binding:host_id`` change. # Open vSwitch and linuxbridge should be OK, but OpenDaylight is at least # one known backend that will not currently work in this case, see bug # https://launchpad.net/bugs/1755890 for more details. # # Possible values: # # * True: wait for ``network-vif-plugged`` events before starting guest transfer # * False: do not wait for ``network-vif-plugged`` events before starting guest # transfer (this is how things have always worked before this option # was introduced) # # Related options: # # * [DEFAULT]/vif_plugging_is_fatal: if ``live_migration_wait_for_vif_plug`` is # True and ``vif_plugging_timeout`` is greater than 0, and a timeout is # reached, the live migration process will fail with an error but the guest # transfer will not have started to the destination host # * [DEFAULT]/vif_plugging_timeout: if ``live_migration_wait_for_vif_plug`` is # True, this controls the amount of time to wait before timing out and either # failing if ``vif_plugging_is_fatal`` is True, or simply continuing with the # live migration # (boolean value) #live_migration_wait_for_vif_plug = false [conductor] # # Options under this group are used to define Conductor's communication, # which manager should be act as a proxy between computes and database, # and finally, how many worker processes will be used. # # From nova.conf # # DEPRECATED: # Topic exchange name on which conductor nodes listen. # (string value) # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # There is no need to let users choose the RPC topic for all services - there # is little gain from this. Furthermore, it makes it really easy to break Nova # by using this option. #topic = conductor # # Number of workers for OpenStack Conductor service. The default will be the # number of CPUs available. # (integer value) #workers = [console] # # Options under this group allow to tune the configuration of the console proxy # service. # # Note: in configuration of every compute is a ``console_host`` option, # which allows to select the console proxy service to connect to. # # From nova.conf # # # Adds list of allowed origins to the console websocket proxy to allow # connections from other origin hostnames. # Websocket proxy matches the host header with the origin header to # prevent cross-site requests. This list specifies if any there are # values other than host are allowed in the origin header. # # Possible values: # # * A list where each element is an allowed origin hostnames, else an empty list # (list value) # Deprecated group/name - [DEFAULT]/console_allowed_origins #allowed_origins = [consoleauth] # # From nova.conf # # # The lifetime of a console auth token (in seconds). # # A console auth token is used in authorizing console access for a user. # Once the auth token time to live count has elapsed, the token is # considered expired. Expired tokens are then deleted. # (integer value) # Minimum value: 0 # Deprecated group/name - [DEFAULT]/console_token_ttl #token_ttl = 600 [cors] # # From oslo.middleware # # Indicate whether this resource may be shared with the domain received in the # requests "origin" header. Format: "://[:]", no trailing # slash. Example: https://horizon.example.com (list value) #allowed_origin = # Indicate that the actual request can include user credentials (boolean value) #allow_credentials = true # Indicate which headers are safe to expose to the API. Defaults to HTTP Simple # Headers. (list value) #expose_headers = X-Auth-Token,X-Openstack-Request-Id,X-Subject-Token,X-Service-Token # Maximum cache age of CORS preflight requests. (integer value) #max_age = 3600 # Indicate which methods can be used during the actual request. (list value) #allow_methods = GET,PUT,POST,DELETE,PATCH # Indicate which header field names may be used during the actual request. (list # value) #allow_headers = X-Auth-Token,X-Openstack-Request-Id,X-Identity-Status,X-Roles,X-Service-Catalog,X-User-Id,X-Tenant-Id [crypto] # # From nova.conf # # # Filename of root CA (Certificate Authority). This is a container format # and includes root certificates. # # Possible values: # # * Any file name containing root CA, cacert.pem is default # # Related options: # # * ca_path # (string value) #ca_file = cacert.pem # # Filename of a private key. # # Related options: # # * keys_path # (string value) #key_file = private/cakey.pem # # Filename of root Certificate Revocation List (CRL). This is a list of # certificates that have been revoked, and therefore, entities presenting # those (revoked) certificates should no longer be trusted. # # Related options: # # * ca_path # (string value) #crl_file = crl.pem # # Directory path where keys are located. # # Related options: # # * key_file # (string value) #keys_path = $state_path/keys # # Directory path where root CA is located. # # Related options: # # * ca_file # (string value) #ca_path = $state_path/CA # Option to enable/disable use of CA for each project. (boolean value) #use_project_ca = false # # Subject for certificate for users, %s for # project, user, timestamp # (string value) #user_cert_subject = /C=US/ST=California/O=OpenStack/OU=NovaDev/CN=%.16s-%.16s-%s # # Subject for certificate for projects, %s for # project, timestamp # (string value) #project_cert_subject = /C=US/ST=California/O=OpenStack/OU=NovaDev/CN=project-ca-%.16s-%s [database] connection = sqlite:////var/lib/nova/nova.sqlite # # From oslo.db # # If True, SQLite uses synchronous mode. (boolean value) #sqlite_synchronous = true # The back end to use for the database. (string value) # Deprecated group/name - [DEFAULT]/db_backend #backend = sqlalchemy # The SQLAlchemy connection string to use to connect to the database. (string # value) # Deprecated group/name - [DEFAULT]/sql_connection # Deprecated group/name - [DATABASE]/sql_connection # Deprecated group/name - [sql]/connection #connection = # The SQLAlchemy connection string to use to connect to the slave database. # (string value) #slave_connection = # The SQL mode to be used for MySQL sessions. This option, including the # default, overrides any server-set SQL mode. To use whatever SQL mode is set by # the server configuration, set this to no value. Example: mysql_sql_mode= # (string value) #mysql_sql_mode = TRADITIONAL # If True, transparently enables support for handling MySQL Cluster (NDB). # (boolean value) #mysql_enable_ndb = false # Connections which have been present in the connection pool longer than this # number of seconds will be replaced with a new one the next time they are # checked out from the pool. (integer value) # Deprecated group/name - [DATABASE]/idle_timeout # Deprecated group/name - [database]/idle_timeout # Deprecated group/name - [DEFAULT]/sql_idle_timeout # Deprecated group/name - [DATABASE]/sql_idle_timeout # Deprecated group/name - [sql]/idle_timeout #connection_recycle_time = 3600 # Minimum number of SQL connections to keep open in a pool. (integer value) # Deprecated group/name - [DEFAULT]/sql_min_pool_size # Deprecated group/name - [DATABASE]/sql_min_pool_size #min_pool_size = 1 # Maximum number of SQL connections to keep open in a pool. Setting a value of 0 # indicates no limit. (integer value) # Deprecated group/name - [DEFAULT]/sql_max_pool_size # Deprecated group/name - [DATABASE]/sql_max_pool_size #max_pool_size = 5 # Maximum number of database connection retries during startup. Set to -1 to # specify an infinite retry count. (integer value) # Deprecated group/name - [DEFAULT]/sql_max_retries # Deprecated group/name - [DATABASE]/sql_max_retries #max_retries = 10 # Interval between retries of opening a SQL connection. (integer value) # Deprecated group/name - [DEFAULT]/sql_retry_interval # Deprecated group/name - [DATABASE]/reconnect_interval #retry_interval = 10 # If set, use this value for max_overflow with SQLAlchemy. (integer value) # Deprecated group/name - [DEFAULT]/sql_max_overflow # Deprecated group/name - [DATABASE]/sqlalchemy_max_overflow #max_overflow = 50 # Verbosity of SQL debugging information: 0=None, 100=Everything. (integer # value) # Minimum value: 0 # Maximum value: 100 # Deprecated group/name - [DEFAULT]/sql_connection_debug #connection_debug = 0 # Add Python stack traces to SQL as comment strings. (boolean value) # Deprecated group/name - [DEFAULT]/sql_connection_trace #connection_trace = false # If set, use this value for pool_timeout with SQLAlchemy. (integer value) # Deprecated group/name - [DATABASE]/sqlalchemy_pool_timeout #pool_timeout = # Enable the experimental use of database reconnect on connection lost. (boolean # value) #use_db_reconnect = false # Seconds between retries of a database transaction. (integer value) #db_retry_interval = 1 # If True, increases the interval between retries of a database operation up to # db_max_retry_interval. (boolean value) #db_inc_retry_interval = true # If db_inc_retry_interval is set, the maximum seconds between retries of a # database operation. (integer value) #db_max_retry_interval = 10 # Maximum retries in case of connection error or deadlock error before error is # raised. Set to -1 to specify an infinite retry count. (integer value) #db_max_retries = 20 # # From oslo.db.concurrency # # Enable the experimental use of thread pooling for all DB API calls (boolean # value) # Deprecated group/name - [DEFAULT]/dbapi_use_tpool #use_tpool = false [devices] # # From nova.conf # # # A list of the vGPU types enabled in the compute node. # # Some pGPUs (e.g. NVIDIA GRID K1) support different vGPU types. User can use # this option to specify a list of enabled vGPU types that may be assigned to a # guest instance. But please note that Nova only supports a single type in the # Queens release. If more than one vGPU type is specified (as a comma-separated # list), only the first one will be used. An example is as the following: # [devices] # enabled_vgpu_types = GRID K100,Intel GVT-g,MxGPU.2,nvidia-11 # (list value) #enabled_vgpu_types = [ephemeral_storage_encryption] # # From nova.conf # # # Enables/disables LVM ephemeral storage encryption. # (boolean value) #enabled = false # # Cipher-mode string to be used. # # The cipher and mode to be used to encrypt ephemeral storage. The set of # cipher-mode combinations available depends on kernel support. According # to the dm-crypt documentation, the cipher is expected to be in the format: # "--". # # Possible values: # # * Any crypto option listed in ``/proc/crypto``. # (string value) #cipher = aes-xts-plain64 # # Encryption key length in bits. # # The bit length of the encryption key to be used to encrypt ephemeral storage. # In XTS mode only half of the bits are used for encryption key. # (integer value) # Minimum value: 1 #key_size = 512 [filter_scheduler] # # From nova.conf # # # Size of subset of best hosts selected by scheduler. # # New instances will be scheduled on a host chosen randomly from a subset of the # N best hosts, where N is the value set by this option. # # Setting this to a value greater than 1 will reduce the chance that multiple # scheduler processes handling similar requests will select the same host, # creating a potential race condition. By selecting a host randomly from the N # hosts that best fit the request, the chance of a conflict is reduced. However, # the higher you set this value, the less optimal the chosen host may be for a # given request. # # This option is only used by the FilterScheduler and its subclasses; if you use # a different scheduler, this option has no effect. # # Possible values: # # * An integer, where the integer corresponds to the size of a host subset. Any # integer is valid, although any value less than 1 will be treated as 1 # (integer value) # Minimum value: 1 # Deprecated group/name - [DEFAULT]/scheduler_host_subset_size #host_subset_size = 1 # # The number of instances that can be actively performing IO on a host. # # Instances performing IO includes those in the following states: build, resize, # snapshot, migrate, rescue, unshelve. # # This option is only used by the FilterScheduler and its subclasses; if you use # a different scheduler, this option has no effect. Also note that this setting # only affects scheduling if the 'io_ops_filter' filter is enabled. # # Possible values: # # * An integer, where the integer corresponds to the max number of instances # that can be actively performing IO on any given host. # (integer value) #max_io_ops_per_host = 8 # # Maximum number of instances that be active on a host. # # If you need to limit the number of instances on any given host, set this # option # to the maximum number of instances you want to allow. The num_instances_filter # will reject any host that has at least as many instances as this option's # value. # # This option is only used by the FilterScheduler and its subclasses; if you use # a different scheduler, this option has no effect. Also note that this setting # only affects scheduling if the 'num_instances_filter' filter is enabled. # # Possible values: # # * An integer, where the integer corresponds to the max instances that can be # scheduled on a host. # (integer value) # Minimum value: 1 #max_instances_per_host = 50 # # Enable querying of individual hosts for instance information. # # The scheduler may need information about the instances on a host in order to # evaluate its filters and weighers. The most common need for this information # is # for the (anti-)affinity filters, which need to choose a host based on the # instances already running on a host. # # If the configured filters and weighers do not need this information, disabling # this option will improve performance. It may also be disabled when the # tracking # overhead proves too heavy, although this will cause classes requiring host # usage data to query the database on each request instead. # # This option is only used by the FilterScheduler and its subclasses; if you use # a different scheduler, this option has no effect. # # NOTE: In a multi-cell (v2) setup where the cell MQ is separated from the # top-level, computes cannot directly communicate with the scheduler. Thus, # this option cannot be enabled in that scenario. See also the # [workarounds]/disable_group_policy_check_upcall option. # (boolean value) # Deprecated group/name - [DEFAULT]/scheduler_tracks_instance_changes #track_instance_changes = true # # Filters that the scheduler can use. # # An unordered list of the filter classes the nova scheduler may apply. Only # the # filters specified in the 'enabled_filters' option will be used, but # any filter appearing in that option must also be included in this list. # # By default, this is set to all filters that are included with nova. # # This option is only used by the FilterScheduler and its subclasses; if you use # a different scheduler, this option has no effect. # # Possible values: # # * A list of zero or more strings, where each string corresponds to the name of # a filter that may be used for selecting a host # # Related options: # # * enabled_filters # (multi valued) # Deprecated group/name - [DEFAULT]/scheduler_available_filters #available_filters = nova.scheduler.filters.all_filters # # Filters that the scheduler will use. # # An ordered list of filter class names that will be used for filtering # hosts. These filters will be applied in the order they are listed so # place your most restrictive filters first to make the filtering process more # efficient. # # This option is only used by the FilterScheduler and its subclasses; if you use # a different scheduler, this option has no effect. # # Possible values: # # * A list of zero or more strings, where each string corresponds to the name of # a filter to be used for selecting a host # # Related options: # # * All of the filters in this option *must* be present in the # 'scheduler_available_filters' option, or a SchedulerHostFilterNotFound # exception will be raised. # (list value) # Deprecated group/name - [DEFAULT]/scheduler_default_filters #enabled_filters = RetryFilter,AvailabilityZoneFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter # DEPRECATED: # Filters used for filtering baremetal hosts. # # Filters are applied in order, so place your most restrictive filters first to # make the filtering process more efficient. # # This option is only used by the FilterScheduler and its subclasses; if you use # a different scheduler, this option has no effect. # # Possible values: # # * A list of zero or more strings, where each string corresponds to the name of # a filter to be used for selecting a baremetal host # # Related options: # # * If the 'scheduler_use_baremetal_filters' option is False, this option has # no effect. # (list value) # Deprecated group/name - [DEFAULT]/baremetal_scheduler_default_filters # This option is deprecated for removal. # Its value may be silently ignored in the future. # Reason: # These filters were used to overcome some of the baremetal scheduling # limitations in Nova prior to the use of the Placement API. Now scheduling will # use the custom resource class defined for each baremetal node to make its # selection. #baremetal_enabled_filters = RetryFilter,AvailabilityZoneFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ExactRamFilter,ExactDiskFilter,ExactCoreFilter # DEPRECATED: # Enable baremetal filters. # # Set this to True to tell the nova scheduler that it should use the filters # specified in the 'baremetal_enabled_filters' option. If you are not # scheduling baremetal nodes, leave this at the default setting of False. # # This option is only used by the FilterScheduler and its subclasses; if you use # a different scheduler, this option has no effect. # # Related options: # # * If this option is set to True, then the filters specified in the # 'baremetal_enabled_filters' are used instead of the filters # specified in 'enabled_filters'. # (boolean value) # Deprecated group/name - [DEFAULT]/scheduler_use_baremetal_filters # This option is deprecated for removal. # Its value may be silently ignored in the future. # Reason: # These filters were used to overcome some of the baremetal scheduling # limitations in Nova prior to the use of the Placement API. Now scheduling will # use the custom resource class defined for each baremetal node to make its # selection. #use_baremetal_filters = false # # Weighers that the scheduler will use. # # Only hosts which pass the filters are weighed. The weight for any host starts # at 0, and the weighers order these hosts by adding to or subtracting from the # weight assigned by the previous weigher. Weights may become negative. An # instance will be scheduled to one of the N most-weighted hosts, where N is # 'scheduler_host_subset_size'. # # By default, this is set to all weighers that are included with Nova. # # This option is only used by the FilterScheduler and its subclasses; if you use # a different scheduler, this option has no effect. # # Possible values: # # * A list of zero or more strings, where each string corresponds to the name of # a weigher that will be used for selecting a host # (list value) # Deprecated group/name - [DEFAULT]/scheduler_weight_classes #weight_classes = nova.scheduler.weights.all_weighers # # Ram weight multipler ratio. # # This option determines how hosts with more or less available RAM are weighed. # A # positive value will result in the scheduler preferring hosts with more # available RAM, and a negative number will result in the scheduler preferring # hosts with less available RAM. Another way to look at it is that positive # values for this option will tend to spread instances across many hosts, while # negative values will tend to fill up (stack) hosts as much as possible before # scheduling to a less-used host. The absolute value, whether positive or # negative, controls how strong the RAM weigher is relative to other weighers. # # This option is only used by the FilterScheduler and its subclasses; if you use # a different scheduler, this option has no effect. Also note that this setting # only affects scheduling if the 'ram' weigher is enabled. # # Possible values: # # * An integer or float value, where the value corresponds to the multipler # ratio for this weigher. # (floating point value) #ram_weight_multiplier = 1.0 # # Disk weight multipler ratio. # # Multiplier used for weighing free disk space. Negative numbers mean to # stack vs spread. # # This option is only used by the FilterScheduler and its subclasses; if you use # a different scheduler, this option has no effect. Also note that this setting # only affects scheduling if the 'disk' weigher is enabled. # # Possible values: # # * An integer or float value, where the value corresponds to the multipler # ratio for this weigher. # (floating point value) #disk_weight_multiplier = 1.0 # # IO operations weight multipler ratio. # # This option determines how hosts with differing workloads are weighed. # Negative # values, such as the default, will result in the scheduler preferring hosts # with # lighter workloads whereas positive values will prefer hosts with heavier # workloads. Another way to look at it is that positive values for this option # will tend to schedule instances onto hosts that are already busy, while # negative values will tend to distribute the workload across more hosts. The # absolute value, whether positive or negative, controls how strong the io_ops # weigher is relative to other weighers. # # This option is only used by the FilterScheduler and its subclasses; if you use # a different scheduler, this option has no effect. Also note that this setting # only affects scheduling if the 'io_ops' weigher is enabled. # # Possible values: # # * An integer or float value, where the value corresponds to the multipler # ratio for this weigher. # (floating point value) #io_ops_weight_multiplier = -1.0 # # PCI device affinity weight multiplier. # # The PCI device affinity weighter computes a weighting based on the number of # PCI devices on the host and the number of PCI devices requested by the # instance. The ``NUMATopologyFilter`` filter must be enabled for this to have # any significance. For more information, refer to the filter documentation: # # https://docs.openstack.org/nova/latest/user/filter-scheduler.html # # Possible values: # # * A positive integer or float value, where the value corresponds to the # multiplier ratio for this weigher. # (floating point value) # Minimum value: 0 #pci_weight_multiplier = 1.0 # # Multiplier used for weighing hosts for group soft-affinity. # # Possible values: # # * An integer or float value, where the value corresponds to weight multiplier # for hosts with group soft affinity. Only a positive value are meaningful, as # negative values would make this behave as a soft anti-affinity weigher. # (floating point value) #soft_affinity_weight_multiplier = 1.0 # # Multiplier used for weighing hosts for group soft-anti-affinity. # # Possible values: # # * An integer or float value, where the value corresponds to weight multiplier # for hosts with group soft anti-affinity. Only a positive value are # meaningful, as negative values would make this behave as a soft affinity # weigher. # (floating point value) #soft_anti_affinity_weight_multiplier = 1.0 # # Multiplier used for weighing hosts that have had recent build failures. # # This option determines how much weight is placed on a compute node with # recent build failures. Build failures may indicate a failing, misconfigured, # or otherwise ailing compute node, and avoiding it during scheduling may be # beneficial. The weight is inversely proportional to the number of recent # build failures the compute node has experienced. This value should be # set to some high value to offset weight given by other enabled weighers # due to available resources. To disable weighing compute hosts by the # number of recent failures, set this to zero. # # This option is only used by the FilterScheduler and its subclasses; if you use # a different scheduler, this option has no effect. # # Possible values: # # * An integer or float value, where the value corresponds to the multiplier # ratio for this weigher. # # Related options: # # * [compute]/consecutive_build_service_disable_threshold - Must be nonzero # for a compute to report data considered by this weigher. # (floating point value) #build_failure_weight_multiplier = 1000000.0 # # Enable spreading the instances between hosts with the same best weight. # # Enabling it is beneficial for cases when host_subset_size is 1 # (default), but there is a large number of hosts with same maximal weight. # This scenario is common in Ironic deployments where there are typically many # baremetal nodes with identical weights returned to the scheduler. # In such case enabling this option will reduce contention and chances for # rescheduling events. # At the same time it will make the instance packing (even in unweighed case) # less dense. # (boolean value) #shuffle_best_same_weighed_hosts = false # # The default architecture to be used when using the image properties filter. # # When using the ImagePropertiesFilter, it is possible that you want to define # a default architecture to make the user experience easier and avoid having # something like x86_64 images landing on aarch64 compute nodes because the # user did not specify the 'hw_architecture' property in Glance. # # Possible values: # # * CPU Architectures such as x86_64, aarch64, s390x. # (string value) # Possible values: # alpha - # armv6 - # armv7l - # armv7b - # aarch64 - # cris - # i686 - # ia64 - # lm32 - # m68k - # microblaze - # microblazeel - # mips - # mipsel - # mips64 - # mips64el - # openrisc - # parisc - # parisc64 - # ppc - # ppcle - # ppc64 - # ppc64le - # ppcemb - # s390 - # s390x - # sh4 - # sh4eb - # sparc - # sparc64 - # unicore32 - # x86_64 - # xtensa - # xtensaeb - #image_properties_default_architecture = # # List of UUIDs for images that can only be run on certain hosts. # # If there is a need to restrict some images to only run on certain designated # hosts, list those image UUIDs here. # # This option is only used by the FilterScheduler and its subclasses; if you use # a different scheduler, this option has no effect. Also note that this setting # only affects scheduling if the 'IsolatedHostsFilter' filter is enabled. # # Possible values: # # * A list of UUID strings, where each string corresponds to the UUID of an # image # # Related options: # # * scheduler/isolated_hosts # * scheduler/restrict_isolated_hosts_to_isolated_images # (list value) #isolated_images = # # List of hosts that can only run certain images. # # If there is a need to restrict some images to only run on certain designated # hosts, list those host names here. # # This option is only used by the FilterScheduler and its subclasses; if you use # a different scheduler, this option has no effect. Also note that this setting # only affects scheduling if the 'IsolatedHostsFilter' filter is enabled. # # Possible values: # # * A list of strings, where each string corresponds to the name of a host # # Related options: # # * scheduler/isolated_images # * scheduler/restrict_isolated_hosts_to_isolated_images # (list value) #isolated_hosts = # # Prevent non-isolated images from being built on isolated hosts. # # This option is only used by the FilterScheduler and its subclasses; if you use # a different scheduler, this option has no effect. Also note that this setting # only affects scheduling if the 'IsolatedHostsFilter' filter is enabled. Even # then, this option doesn't affect the behavior of requests for isolated images, # which will *always* be restricted to isolated hosts. # # Related options: # # * scheduler/isolated_images # * scheduler/isolated_hosts # (boolean value) #restrict_isolated_hosts_to_isolated_images = true # # Image property namespace for use in the host aggregate. # # Images and hosts can be configured so that certain images can only be # scheduled # to hosts in a particular aggregate. This is done with metadata values set on # the host aggregate that are identified by beginning with the value of this # option. If the host is part of an aggregate with such a metadata key, the # image # in the request spec must have the value of that metadata in its properties in # order for the scheduler to consider the host as acceptable. # # This option is only used by the FilterScheduler and its subclasses; if you use # a different scheduler, this option has no effect. Also note that this setting # only affects scheduling if the 'aggregate_image_properties_isolation' filter # is # enabled. # # Possible values: # # * A string, where the string corresponds to an image property namespace # # Related options: # # * aggregate_image_properties_isolation_separator # (string value) #aggregate_image_properties_isolation_namespace = # # Separator character(s) for image property namespace and name. # # When using the aggregate_image_properties_isolation filter, the relevant # metadata keys are prefixed with the namespace defined in the # aggregate_image_properties_isolation_namespace configuration option plus a # separator. This option defines the separator to be used. # # This option is only used by the FilterScheduler and its subclasses; if you use # a different scheduler, this option has no effect. Also note that this setting # only affects scheduling if the 'aggregate_image_properties_isolation' filter # is enabled. # # Possible values: # # * A string, where the string corresponds to an image property namespace # separator character # # Related options: # # * aggregate_image_properties_isolation_namespace # (string value) #aggregate_image_properties_isolation_separator = . [glance] # Configuration options for the Image service #pavlos api_servers = http://controller:9292 # # From nova.conf # # # List of glance api servers endpoints available to nova. # # https is used for ssl-based glance api servers. # # NOTE: The preferred mechanism for endpoint discovery is via keystoneauth1 # loading options. Only use api_servers if you need multiple endpoints and are # unable to use a load balancer for some reason. # # Possible values: # # * A list of any fully qualified url of the form # "scheme://hostname:port[/path]" # (i.e. "http://10.0.1.0:9292" or "https://my.glance.server/image"). # (list value) #api_servers = # # Enable glance operation retries. # # Specifies the number of retries when uploading / downloading # an image to / from glance. 0 means no retries. # (integer value) # Minimum value: 0 #num_retries = 0 # DEPRECATED: # List of url schemes that can be directly accessed. # # This option specifies a list of url schemes that can be downloaded # directly via the direct_url. This direct_URL can be fetched from # Image metadata which can be used by nova to get the # image more efficiently. nova-compute could benefit from this by # invoking a copy when it has access to the same file system as glance. # # Possible values: # # * [file], Empty list (default) # (list value) # This option is deprecated for removal since 17.0.0. # Its value may be silently ignored in the future. # Reason: # This was originally added for the 'nova.image.download.file' FileTransfer # extension which was removed in the 16.0.0 Pike release. The # 'nova.image.download.modules' extension point is not maintained # and there is no indication of its use in production clouds. #allowed_direct_url_schemes = # # Enable image signature verification. # # nova uses the image signature metadata from glance and verifies the signature # of a signed image while downloading that image. If the image signature cannot # be verified or if the image signature metadata is either incomplete or # unavailable, then nova will not boot the image and instead will place the # instance into an error state. This provides end users with stronger assurances # of the integrity of the image data they are using to create servers. # # Related options: # # * The options in the `key_manager` group, as the key_manager is used # for the signature validation. # * Both enable_certificate_validation and default_trusted_certificate_ids # below depend on this option being enabled. # (boolean value) #verify_glance_signatures = false # DEPRECATED: # Enable certificate validation for image signature verification. # # During image signature verification nova will first verify the validity of the # image's signing certificate using the set of trusted certificates associated # with the instance. If certificate validation fails, signature verification # will not be performed and the image will be placed into an error state. This # provides end users with stronger assurances that the image data is unmodified # and trustworthy. If left disabled, image signature verification can still # occur but the end user will not have any assurance that the signing # certificate used to generate the image signature is still trustworthy. # # Related options: # # * This option only takes effect if verify_glance_signatures is enabled. # * The value of default_trusted_certificate_ids may be used when this option # is enabled. # (boolean value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # This option is intended to ease the transition for deployments leveraging # image signature verification. The intended state long-term is for signature # verification and certificate validation to always happen together. #enable_certificate_validation = false # # List of certificate IDs for certificates that should be trusted. # # May be used as a default list of trusted certificate IDs for certificate # validation. The value of this option will be ignored if the user provides a # list of trusted certificate IDs with an instance API request. The value of # this option will be persisted with the instance data if signature verification # and certificate validation are enabled and if the user did not provide an # alternative list. If left empty when certificate validation is enabled the # user must provide a list of trusted certificate IDs otherwise certificate # validation will fail. # # Related options: # # * The value of this option may be used if both verify_glance_signatures and # enable_certificate_validation are enabled. # (list value) #default_trusted_certificate_ids = # Enable or disable debug logging with glanceclient. (boolean value) #debug = false # PEM encoded Certificate Authority to use when verifying HTTPs connections. # (string value) #cafile = # PEM encoded client certificate cert file (string value) #certfile = # PEM encoded client certificate key file (string value) #keyfile = # Verify HTTPS connections. (boolean value) #insecure = false # Timeout value for http requests (integer value) #timeout = # The default service_type for endpoint URL discovery. (string value) #service_type = image # The default service_name for endpoint URL discovery. (string value) #service_name = # List of interfaces, in order of preference, for endpoint URL. (list value) #valid_interfaces = internal,public # The default region_name for endpoint URL discovery. (string value) #region_name = # Always use this endpoint URL for requests for this client. NOTE: The # unversioned endpoint should be specified here; to request a particular API # version, use the `version`, `min-version`, and/or `max-version` options. # (string value) #endpoint_override = [guestfs] # # libguestfs is a set of tools for accessing and modifying virtual # machine (VM) disk images. You can use this for viewing and editing # files inside guests, scripting changes to VMs, monitoring disk # used/free statistics, creating guests, P2V, V2V, performing backups, # cloning VMs, building VMs, formatting disks and resizing disks. # # From nova.conf # # # Enable/disables guestfs logging. # # This configures guestfs to debug messages and push them to OpenStack # logging system. When set to True, it traces libguestfs API calls and # enable verbose debug messages. In order to use the above feature, # "libguestfs" package must be installed. # # Related options: # Since libguestfs access and modifies VM's managed by libvirt, below options # should be set to give access to those VM's. # * libvirt.inject_key # * libvirt.inject_partition # * libvirt.inject_password # (boolean value) #debug = false [healthcheck] # # From oslo.middleware # # DEPRECATED: The path to respond to healtcheck requests on. (string value) # This option is deprecated for removal. # Its value may be silently ignored in the future. #path = /healthcheck # Show more detailed information as part of the response (boolean value) #detailed = false # Additional backends that can perform health checks and report that information # back as part of a request. (list value) #backends = # Check the presence of a file to determine if an application is running on a # port. Used by DisableByFileHealthcheck plugin. (string value) #disable_by_file_path = # Check the presence of a file based on a port to determine if an application is # running on a port. Expects a "port:path" list of strings. Used by # DisableByFilesPortsHealthcheck plugin. (list value) #disable_by_file_paths = [hyperv] # # The hyperv feature allows you to configure the Hyper-V hypervisor # driver to be used within an OpenStack deployment. # # From nova.conf # # # Dynamic memory ratio # # Enables dynamic memory allocation (ballooning) when set to a value # greater than 1. The value expresses the ratio between the total RAM # assigned to an instance and its startup RAM amount. For example a # ratio of 2.0 for an instance with 1024MB of RAM implies 512MB of # RAM allocated at startup. # # Possible values: # # * 1.0: Disables dynamic memory allocation (Default). # * Float values greater than 1.0: Enables allocation of total implied # RAM divided by this value for startup. # (floating point value) #dynamic_memory_ratio = 1.0 # # Enable instance metrics collection # # Enables metrics collections for an instance by using Hyper-V's # metric APIs. Collected data can be retrieved by other apps and # services, e.g.: Ceilometer. # (boolean value) #enable_instance_metrics_collection = false # # Instances path share # # The name of a Windows share mapped to the "instances_path" dir # and used by the resize feature to copy files to the target host. # If left blank, an administrative share (hidden network share) will # be used, looking for the same "instances_path" used locally. # # Possible values: # # * "": An administrative share will be used (Default). # * Name of a Windows share. # # Related options: # # * "instances_path": The directory which will be used if this option # here is left blank. # (string value) #instances_path_share = # # Limit CPU features # # This flag is needed to support live migration to hosts with # different CPU features and checked during instance creation # in order to limit the CPU features used by the instance. # (boolean value) #limit_cpu_features = false # # Mounted disk query retry count # # The number of times to retry checking for a mounted disk. # The query runs until the device can be found or the retry # count is reached. # # Possible values: # # * Positive integer values. Values greater than 1 is recommended # (Default: 10). # # Related options: # # * Time interval between disk mount retries is declared with # "mounted_disk_query_retry_interval" option. # (integer value) # Minimum value: 0 #mounted_disk_query_retry_count = 10 # # Mounted disk query retry interval # # Interval between checks for a mounted disk, in seconds. # # Possible values: # # * Time in seconds (Default: 5). # # Related options: # # * This option is meaningful when the mounted_disk_query_retry_count # is greater than 1. # * The retry loop runs with mounted_disk_query_retry_count and # mounted_disk_query_retry_interval configuration options. # (integer value) # Minimum value: 0 #mounted_disk_query_retry_interval = 5 # # Power state check timeframe # # The timeframe to be checked for instance power state changes. # This option is used to fetch the state of the instance from Hyper-V # through the WMI interface, within the specified timeframe. # # Possible values: # # * Timeframe in seconds (Default: 60). # (integer value) # Minimum value: 0 #power_state_check_timeframe = 60 # # Power state event polling interval # # Instance power state change event polling frequency. Sets the # listener interval for power state events to the given value. # This option enhances the internal lifecycle notifications of # instances that reboot themselves. It is unlikely that an operator # has to change this value. # # Possible values: # # * Time in seconds (Default: 2). # (integer value) # Minimum value: 0 #power_state_event_polling_interval = 2 # # qemu-img command # # qemu-img is required for some of the image related operations # like converting between different image types. You can get it # from here: (http://qemu.weilnetz.de/) or you can install the # Cloudbase OpenStack Hyper-V Compute Driver # (https://cloudbase.it/openstack-hyperv-driver/) which automatically # sets the proper path for this config option. You can either give the # full path of qemu-img.exe or set its path in the PATH environment # variable and leave this option to the default value. # # Possible values: # # * Name of the qemu-img executable, in case it is in the same # directory as the nova-compute service or its path is in the # PATH environment variable (Default). # * Path of qemu-img command (DRIVELETTER:\PATH\TO\QEMU-IMG\COMMAND). # # Related options: # # * If the config_drive_cdrom option is False, qemu-img will be used to # convert the ISO to a VHD, otherwise the configuration drive will # remain an ISO. To use configuration drive with Hyper-V, you must # set the mkisofs_cmd value to the full path to an mkisofs.exe # installation. # (string value) #qemu_img_cmd = qemu-img.exe # # External virtual switch name # # The Hyper-V Virtual Switch is a software-based layer-2 Ethernet # network switch that is available with the installation of the # Hyper-V server role. The switch includes programmatically managed # and extensible capabilities to connect virtual machines to both # virtual networks and the physical network. In addition, Hyper-V # Virtual Switch provides policy enforcement for security, isolation, # and service levels. The vSwitch represented by this config option # must be an external one (not internal or private). # # Possible values: # # * If not provided, the first of a list of available vswitches # is used. This list is queried using WQL. # * Virtual switch name. # (string value) #vswitch_name = # # Wait soft reboot seconds # # Number of seconds to wait for instance to shut down after soft # reboot request is made. We fall back to hard reboot if instance # does not shutdown within this window. # # Possible values: # # * Time in seconds (Default: 60). # (integer value) # Minimum value: 0 #wait_soft_reboot_seconds = 60 # # Configuration drive cdrom # # OpenStack can be configured to write instance metadata to # a configuration drive, which is then attached to the # instance before it boots. The configuration drive can be # attached as a disk drive (default) or as a CD drive. # # Possible values: # # * True: Attach the configuration drive image as a CD drive. # * False: Attach the configuration drive image as a disk drive (Default). # # Related options: # # * This option is meaningful with force_config_drive option set to 'True' # or when the REST API call to create an instance will have # '--config-drive=True' flag. # * config_drive_format option must be set to 'iso9660' in order to use # CD drive as the configuration drive image. # * To use configuration drive with Hyper-V, you must set the # mkisofs_cmd value to the full path to an mkisofs.exe installation. # Additionally, you must set the qemu_img_cmd value to the full path # to an qemu-img command installation. # * You can configure the Compute service to always create a configuration # drive by setting the force_config_drive option to 'True'. # (boolean value) #config_drive_cdrom = false # # Configuration drive inject password # # Enables setting the admin password in the configuration drive image. # # Related options: # # * This option is meaningful when used with other options that enable # configuration drive usage with Hyper-V, such as force_config_drive. # * Currently, the only accepted config_drive_format is 'iso9660'. # (boolean value) #config_drive_inject_password = false # # Volume attach retry count # # The number of times to retry attaching a volume. Volume attachment # is retried until success or the given retry count is reached. # # Possible values: # # * Positive integer values (Default: 10). # # Related options: # # * Time interval between attachment attempts is declared with # volume_attach_retry_interval option. # (integer value) # Minimum value: 0 #volume_attach_retry_count = 10 # # Volume attach retry interval # # Interval between volume attachment attempts, in seconds. # # Possible values: # # * Time in seconds (Default: 5). # # Related options: # # * This options is meaningful when volume_attach_retry_count # is greater than 1. # * The retry loop runs with volume_attach_retry_count and # volume_attach_retry_interval configuration options. # (integer value) # Minimum value: 0 #volume_attach_retry_interval = 5 # # Enable RemoteFX feature # # This requires at least one DirectX 11 capable graphics adapter for # Windows / Hyper-V Server 2012 R2 or newer and RDS-Virtualization # feature has to be enabled. # # Instances with RemoteFX can be requested with the following flavor # extra specs: # # **os:resolution**. Guest VM screen resolution size. Acceptable values:: # # 1024x768, 1280x1024, 1600x1200, 1920x1200, 2560x1600, 3840x2160 # # ``3840x2160`` is only available on Windows / Hyper-V Server 2016. # # **os:monitors**. Guest VM number of monitors. Acceptable values:: # # [1, 4] - Windows / Hyper-V Server 2012 R2 # [1, 8] - Windows / Hyper-V Server 2016 # # **os:vram**. Guest VM VRAM amount. Only available on # Windows / Hyper-V Server 2016. Acceptable values:: # # 64, 128, 256, 512, 1024 # (boolean value) #enable_remotefx = false # # Use multipath connections when attaching iSCSI or FC disks. # # This requires the Multipath IO Windows feature to be enabled. MPIO must be # configured to claim such devices. # (boolean value) #use_multipath_io = false # # List of iSCSI initiators that will be used for estabilishing iSCSI sessions. # # If none are specified, the Microsoft iSCSI initiator service will choose the # initiator. # (list value) #iscsi_initiator_list = [ironic] # # Configuration options for Ironic driver (Bare Metal). # If using the Ironic driver following options must be set: # * auth_type # * auth_url # * project_name # * username # * password # * project_domain_id or project_domain_name # * user_domain_id or user_domain_name # # From nova.conf # # DEPRECATED: URL override for the Ironic API endpoint. (uri value) # This option is deprecated for removal. # Its value may be silently ignored in the future. # Reason: Endpoint lookup uses the service catalog via common keystoneauth1 # Adapter configuration options. In the current release, api_endpoint will # override this behavior, but will be ignored and/or removed in a future # release. To achieve the same result, use the endpoint_override option instead. #api_endpoint = http://ironic.example.org:6385/ # # The number of times to retry when a request conflicts. # If set to 0, only try once, no retries. # # Related options: # # * api_retry_interval # (integer value) # Minimum value: 0 #api_max_retries = 60 # # The number of seconds to wait before retrying the request. # # Related options: # # * api_max_retries # (integer value) # Minimum value: 0 #api_retry_interval = 2 # Timeout (seconds) to wait for node serial console state changed. Set to 0 to # disable timeout. (integer value) # Minimum value: 0 #serial_console_state_timeout = 10 # PEM encoded Certificate Authority to use when verifying HTTPs connections. # (string value) #cafile = # PEM encoded client certificate cert file (string value) #certfile = # PEM encoded client certificate key file (string value) #keyfile = # Verify HTTPS connections. (boolean value) #insecure = false # Timeout value for http requests (integer value) #timeout = # Authentication type to load (string value) # Deprecated group/name - [ironic]/auth_plugin #auth_type = # Config Section from which to load plugin specific options (string value) #auth_section = # Authentication URL (string value) #auth_url = # Scope for system operations (string value) #system_scope = # Domain ID to scope to (string value) #domain_id = # Domain name to scope to (string value) #domain_name = # Project ID to scope to (string value) #project_id = # Project name to scope to (string value) #project_name = # Domain ID containing project (string value) #project_domain_id = # Domain name containing project (string value) #project_domain_name = # Trust ID (string value) #trust_id = # User ID (string value) #user_id = # Username (string value) # Deprecated group/name - [ironic]/user_name #username = # User's domain id (string value) #user_domain_id = # User's domain name (string value) #user_domain_name = # User's password (string value) #password = # The default service_type for endpoint URL discovery. (string value) #service_type = baremetal # The default service_name for endpoint URL discovery. (string value) #service_name = # List of interfaces, in order of preference, for endpoint URL. (list value) #valid_interfaces = internal,public # The default region_name for endpoint URL discovery. (string value) #region_name = # Always use this endpoint URL for requests for this client. NOTE: The # unversioned endpoint should be specified here; to request a particular API # version, use the `version`, `min-version`, and/or `max-version` options. # (string value) # Deprecated group/name - [ironic]/api_endpoint #endpoint_override = [key_manager] # # From nova.conf # # # Fixed key returned by key manager, specified in hex. # # Possible values: # # * Empty string or a key in hex value # (string value) #fixed_key = # Specify the key manager implementation. Options are "barbican" and "vault". # Default is "barbican". Will support the values earlier set using # [key_manager]/api_class for some time. (string value) # Deprecated group/name - [key_manager]/api_class #backend = barbican # The type of authentication credential to create. Possible values are 'token', # 'password', 'keystone_token', and 'keystone_password'. Required if no context # is passed to the credential factory. (string value) #auth_type = # Token for authentication. Required for 'token' and 'keystone_token' auth_type # if no context is passed to the credential factory. (string value) #token = # Username for authentication. Required for 'password' auth_type. Optional for # the 'keystone_password' auth_type. (string value) #username = # Password for authentication. Required for 'password' and 'keystone_password' # auth_type. (string value) #password = # Use this endpoint to connect to Keystone. (string value) #auth_url = # User ID for authentication. Optional for 'keystone_token' and # 'keystone_password' auth_type. (string value) #user_id = # User's domain ID for authentication. Optional for 'keystone_token' and # 'keystone_password' auth_type. (string value) #user_domain_id = # User's domain name for authentication. Optional for 'keystone_token' and # 'keystone_password' auth_type. (string value) #user_domain_name = # Trust ID for trust scoping. Optional for 'keystone_token' and # 'keystone_password' auth_type. (string value) #trust_id = # Domain ID for domain scoping. Optional for 'keystone_token' and # 'keystone_password' auth_type. (string value) #domain_id = # Domain name for domain scoping. Optional for 'keystone_token' and # 'keystone_password' auth_type. (string value) #domain_name = # Project ID for project scoping. Optional for 'keystone_token' and # 'keystone_password' auth_type. (string value) #project_id = # Project name for project scoping. Optional for 'keystone_token' and # 'keystone_password' auth_type. (string value) #project_name = # Project's domain ID for project. Optional for 'keystone_token' and # 'keystone_password' auth_type. (string value) #project_domain_id = # Project's domain name for project. Optional for 'keystone_token' and # 'keystone_password' auth_type. (string value) #project_domain_name = # Allow fetching a new token if the current one is going to expire. Optional for # 'keystone_token' and 'keystone_password' auth_type. (boolean value) #reauthenticate = true [keystone] # Configuration options for the identity service # # From nova.conf # # PEM encoded Certificate Authority to use when verifying HTTPs connections. # (string value) #cafile = # PEM encoded client certificate cert file (string value) #certfile = # PEM encoded client certificate key file (string value) #keyfile = # Verify HTTPS connections. (boolean value) #insecure = false # Timeout value for http requests (integer value) #timeout = # The default service_type for endpoint URL discovery. (string value) #service_type = identity # The default service_name for endpoint URL discovery. (string value) #service_name = # List of interfaces, in order of preference, for endpoint URL. (list value) #valid_interfaces = internal,public # The default region_name for endpoint URL discovery. (string value) #region_name = # Always use this endpoint URL for requests for this client. NOTE: The # unversioned endpoint should be specified here; to request a particular API # version, use the `version`, `min-version`, and/or `max-version` options. # (string value) #endpoint_override = [keystone_authtoken] #pavlos --start auth_url = http://controller/identity/v3 #auth_url = http://controller:5000/v3 #auth_url = http://192.168.40.184/identity memcached_servers = controller:11211 auth_type = password project_domain_name = default user_domain_name = default project_name = service username = nova password = linux #pavlos --end # # From keystonemiddleware.auth_token # # Complete "public" Identity API endpoint. This endpoint should not be an # "admin" endpoint, as it should be accessible by all end users. Unauthenticated # clients are redirected to this endpoint to authenticate. Although this # endpoint should ideally be unversioned, client support in the wild varies. If # you're using a versioned v2 endpoint here, then this should *not* be the same # endpoint the service user utilizes for validating tokens, because normal end # users may not be able to reach that endpoint. (string value) # Deprecated group/name - [keystone_authtoken]/auth_uri #www_authenticate_uri = # DEPRECATED: Complete "public" Identity API endpoint. This endpoint should not # be an "admin" endpoint, as it should be accessible by all end users. # Unauthenticated clients are redirected to this endpoint to authenticate. # Although this endpoint should ideally be unversioned, client support in the # wild varies. If you're using a versioned v2 endpoint here, then this should # *not* be the same endpoint the service user utilizes for validating tokens, # because normal end users may not be able to reach that endpoint. This option # is deprecated in favor of www_authenticate_uri and will be removed in the S # release. (string value) # This option is deprecated for removal since Queens. # Its value may be silently ignored in the future. # Reason: The auth_uri option is deprecated in favor of www_authenticate_uri and # will be removed in the S release. #auth_uri = # API version of the admin Identity API endpoint. (string value) #auth_version = # Do not handle authorization requests within the middleware, but delegate the # authorization decision to downstream WSGI components. (boolean value) #delay_auth_decision = false # Request timeout value for communicating with Identity API server. (integer # value) #http_connect_timeout = # How many times are we trying to reconnect when communicating with Identity API # Server. (integer value) #http_request_max_retries = 3 # Request environment key where the Swift cache object is stored. When # auth_token middleware is deployed with a Swift cache, use this option to have # the middleware share a caching backend with swift. Otherwise, use the # ``memcached_servers`` option instead. (string value) #cache = # Required if identity server requires client certificate (string value) #certfile = # Required if identity server requires client certificate (string value) #keyfile = # A PEM encoded Certificate Authority to use when verifying HTTPs connections. # Defaults to system CAs. (string value) #cafile = # Verify HTTPS connections. (boolean value) #insecure = false # The region in which the identity server can be found. (string value) #region_name = # DEPRECATED: Directory used to cache files related to PKI tokens. This option # has been deprecated in the Ocata release and will be removed in the P release. # (string value) # This option is deprecated for removal since Ocata. # Its value may be silently ignored in the future. # Reason: PKI token format is no longer supported. #signing_dir = # Optionally specify a list of memcached server(s) to use for caching. If left # undefined, tokens will instead be cached in-process. (list value) # Deprecated group/name - [keystone_authtoken]/memcache_servers #memcached_servers = # In order to prevent excessive effort spent validating tokens, the middleware # caches previously-seen tokens for a configurable duration (in seconds). Set to # -1 to disable caching completely. (integer value) #token_cache_time = 300 # DEPRECATED: Determines the frequency at which the list of revoked tokens is # retrieved from the Identity service (in seconds). A high number of revocation # events combined with a low cache duration may significantly reduce # performance. Only valid for PKI tokens. This option has been deprecated in the # Ocata release and will be removed in the P release. (integer value) # This option is deprecated for removal since Ocata. # Its value may be silently ignored in the future. # Reason: PKI token format is no longer supported. #revocation_cache_time = 10 # (Optional) If defined, indicate whether token data should be authenticated or # authenticated and encrypted. If MAC, token data is authenticated (with HMAC) # in the cache. If ENCRYPT, token data is encrypted and authenticated in the # cache. If the value is not one of these options or empty, auth_token will # raise an exception on initialization. (string value) # Possible values: # None - # MAC - # ENCRYPT - #memcache_security_strategy = None # (Optional, mandatory if memcache_security_strategy is defined) This string is # used for key derivation. (string value) #memcache_secret_key = # (Optional) Number of seconds memcached server is considered dead before it is # tried again. (integer value) #memcache_pool_dead_retry = 300 # (Optional) Maximum total number of open connections to every memcached server. # (integer value) #memcache_pool_maxsize = 10 # (Optional) Socket timeout in seconds for communicating with a memcached # server. (integer value) #memcache_pool_socket_timeout = 3 # (Optional) Number of seconds a connection to memcached is held unused in the # pool before it is closed. (integer value) #memcache_pool_unused_timeout = 60 # (Optional) Number of seconds that an operation will wait to get a memcached # client connection from the pool. (integer value) #memcache_pool_conn_get_timeout = 10 # (Optional) Use the advanced (eventlet safe) memcached client pool. The # advanced pool will only work under python 2.x. (boolean value) #memcache_use_advanced_pool = false # (Optional) Indicate whether to set the X-Service-Catalog header. If False, # middleware will not ask for service catalog on token validation and will not # set the X-Service-Catalog header. (boolean value) #include_service_catalog = true # Used to control the use and type of token binding. Can be set to: "disabled" # to not check token binding. "permissive" (default) to validate binding # information if the bind type is of a form known to the server and ignore it if # not. "strict" like "permissive" but if the bind type is unknown the token will # be rejected. "required" any form of token binding is needed to be allowed. # Finally the name of a binding method that must be present in tokens. (string # value) #enforce_token_bind = permissive # DEPRECATED: If true, the revocation list will be checked for cached tokens. # This requires that PKI tokens are configured on the identity server. (boolean # value) # This option is deprecated for removal since Ocata. # Its value may be silently ignored in the future. # Reason: PKI token format is no longer supported. #check_revocations_for_cached = false # DEPRECATED: Hash algorithms to use for hashing PKI tokens. This may be a # single algorithm or multiple. The algorithms are those supported by Python # standard hashlib.new(). The hashes will be tried in the order given, so put # the preferred one first for performance. The result of the first hash will be # stored in the cache. This will typically be set to multiple values only while # migrating from a less secure algorithm to a more secure one. Once all the old # tokens are expired this option should be set to a single value for better # performance. (list value) # This option is deprecated for removal since Ocata. # Its value may be silently ignored in the future. # Reason: PKI token format is no longer supported. #hash_algorithms = md5 # A choice of roles that must be present in a service token. Service tokens are # allowed to request that an expired token can be used and so this check should # tightly control that only actual services should be sending this token. Roles # here are applied as an ANY check so any role in this list must be present. For # backwards compatibility reasons this currently only affects the allow_expired # check. (list value) #service_token_roles = service # For backwards compatibility reasons we must let valid service tokens pass that # don't pass the service_token_roles check as valid. Setting this true will # become the default in a future release and should be enabled if possible. # (boolean value) #service_token_roles_required = false # Prefix to prepend at the beginning of the path. Deprecated, use identity_uri. # (string value) #auth_admin_prefix = # Host providing the admin Identity API endpoint. Deprecated, use identity_uri. # (string value) #auth_host = 127.0.0.1 # Port of the admin Identity API endpoint. Deprecated, use identity_uri. # (integer value) #auth_port = 35357 # Protocol of the admin Identity API endpoint. Deprecated, use identity_uri. # (string value) # Possible values: # http - # https - #auth_protocol = https # Complete admin Identity API endpoint. This should specify the unversioned root # endpoint e.g. https://localhost:35357/ (string value) #identity_uri = # This option is deprecated and may be removed in a future release. Single # shared secret with the Keystone configuration used for bootstrapping a # Keystone installation, or otherwise bypassing the normal authentication # process. This option should not be used, use `admin_user` and `admin_password` # instead. (string value) #admin_token = # Service username. (string value) #admin_user = # Service user password. (string value) #admin_password = # Service tenant name. (string value) #admin_tenant_name = admin # Authentication type to load (string value) # Deprecated group/name - [keystone_authtoken]/auth_plugin #auth_type = # Config Section from which to load plugin specific options (string value) #auth_section = [libvirt] # # Libvirt options allows cloud administrator to configure related # libvirt hypervisor driver to be used within an OpenStack deployment. # # Almost all of the libvirt config options are influence by ``virt_type`` config # which describes the virtualization type (or so called domain type) libvirt # should use for specific features such as live migration, snapshot. # # From nova.conf # # # The ID of the image to boot from to rescue data from a corrupted instance. # # If the rescue REST API operation doesn't provide an ID of an image to # use, the image which is referenced by this ID is used. If this # option is not set, the image from the instance is used. # # Possible values: # # * An ID of an image or nothing. If it points to an *Amazon Machine # Image* (AMI), consider to set the config options ``rescue_kernel_id`` # and ``rescue_ramdisk_id`` too. If nothing is set, the image of the instance # is used. # # Related options: # # * ``rescue_kernel_id``: If the chosen rescue image allows the separate # definition of its kernel disk, the value of this option is used, # if specified. This is the case when *Amazon*'s AMI/AKI/ARI image # format is used for the rescue image. # * ``rescue_ramdisk_id``: If the chosen rescue image allows the separate # definition of its RAM disk, the value of this option is used if, # specified. This is the case when *Amazon*'s AMI/AKI/ARI image # format is used for the rescue image. # (string value) #rescue_image_id = # # The ID of the kernel (AKI) image to use with the rescue image. # # If the chosen rescue image allows the separate definition of its kernel # disk, the value of this option is used, if specified. This is the case # when *Amazon*'s AMI/AKI/ARI image format is used for the rescue image. # # Possible values: # # * An ID of an kernel image or nothing. If nothing is specified, the kernel # disk from the instance is used if it was launched with one. # # Related options: # # * ``rescue_image_id``: If that option points to an image in *Amazon*'s # AMI/AKI/ARI image format, it's useful to use ``rescue_kernel_id`` too. # (string value) #rescue_kernel_id = # # The ID of the RAM disk (ARI) image to use with the rescue image. # # If the chosen rescue image allows the separate definition of its RAM # disk, the value of this option is used, if specified. This is the case # when *Amazon*'s AMI/AKI/ARI image format is used for the rescue image. # # Possible values: # # * An ID of a RAM disk image or nothing. If nothing is specified, the RAM # disk from the instance is used if it was launched with one. # # Related options: # # * ``rescue_image_id``: If that option points to an image in *Amazon*'s # AMI/AKI/ARI image format, it's useful to use ``rescue_ramdisk_id`` too. # (string value) #rescue_ramdisk_id = # # Describes the virtualization type (or so called domain type) libvirt should # use. # # The choice of this type must match the underlying virtualization strategy # you have chosen for this host. # # Possible values: # # * See the predefined set of case-sensitive values. # # Related options: # # * ``connection_uri``: depends on this # * ``disk_prefix``: depends on this # * ``cpu_mode``: depends on this # * ``cpu_model``: depends on this # (string value) # Possible values: # kvm - # lxc - # qemu - # uml - # xen - # parallels - #virt_type = kvm # # Overrides the default libvirt URI of the chosen virtualization type. # # If set, Nova will use this URI to connect to libvirt. # # Possible values: # # * An URI like ``qemu:///system`` or ``xen+ssh://oirase/`` for example. # This is only necessary if the URI differs to the commonly known URIs # for the chosen virtualization type. # # Related options: # # * ``virt_type``: Influences what is used as default value here. # (string value) #connection_uri = # # Allow the injection of an admin password for instance only at ``create`` and # ``rebuild`` process. # # There is no agent needed within the image to do this. If *libguestfs* is # available on the host, it will be used. Otherwise *nbd* is used. The file # system of the image will be mounted and the admin password, which is provided # in the REST API call will be injected as password for the root user. If no # root user is available, the instance won't be launched and an error is thrown. # Be aware that the injection is *not* possible when the instance gets launched # from a volume. # # Possible values: # # * True: Allows the injection. # * False (default): Disallows the injection. Any via the REST API provided # admin password will be silently ignored. # # Related options: # # * ``inject_partition``: That option will decide about the discovery and usage # of the file system. It also can disable the injection at all. # (boolean value) #inject_password = false # # Allow the injection of an SSH key at boot time. # # There is no agent needed within the image to do this. If *libguestfs* is # available on the host, it will be used. Otherwise *nbd* is used. The file # system of the image will be mounted and the SSH key, which is provided # in the REST API call will be injected as SSH key for the root user and # appended to the ``authorized_keys`` of that user. The SELinux context will # be set if necessary. Be aware that the injection is *not* possible when the # instance gets launched from a volume. # # This config option will enable directly modifying the instance disk and does # not affect what cloud-init may do using data from config_drive option or the # metadata service. # # Related options: # # * ``inject_partition``: That option will decide about the discovery and usage # of the file system. It also can disable the injection at all. # (boolean value) #inject_key = false # # Determines the way how the file system is chosen to inject data into it. # # *libguestfs* will be used a first solution to inject data. If that's not # available on the host, the image will be locally mounted on the host as a # fallback solution. If libguestfs is not able to determine the root partition # (because there are more or less than one root partition) or cannot mount the # file system it will result in an error and the instance won't be boot. # # Possible values: # # * -2 => disable the injection of data. # * -1 => find the root partition with the file system to mount with libguestfs # * 0 => The image is not partitioned # * >0 => The number of the partition to use for the injection # # Related options: # # * ``inject_key``: If this option allows the injection of a SSH key it depends # on value greater or equal to -1 for ``inject_partition``. # * ``inject_password``: If this option allows the injection of an admin # password # it depends on value greater or equal to -1 for ``inject_partition``. # * ``guestfs`` You can enable the debug log level of libguestfs with this # config option. A more verbose output will help in debugging issues. # * ``virt_type``: If you use ``lxc`` as virt_type it will be treated as a # single partition image # (integer value) # Minimum value: -2 #inject_partition = -2 # DEPRECATED: # Enable a mouse cursor within a graphical VNC or SPICE sessions. # # This will only be taken into account if the VM is fully virtualized and VNC # and/or SPICE is enabled. If the node doesn't support a graphical framebuffer, # then it is valid to set this to False. # # Related options: # * ``[vnc]enabled``: If VNC is enabled, ``use_usb_tablet`` will have an effect. # * ``[spice]enabled`` + ``[spice].agent_enabled``: If SPICE is enabled and the # spice agent is disabled, the config value of ``use_usb_tablet`` will have # an effect. # (boolean value) # This option is deprecated for removal since 14.0.0. # Its value may be silently ignored in the future. # Reason: This option is being replaced by the 'pointer_model' option. #use_usb_tablet = true # # The IP address or hostname to be used as the target for live migration # traffic. # # If this option is set to None, the hostname of the migration target compute # node will be used. # # This option is useful in environments where the live-migration traffic can # impact the network plane significantly. A separate network for live-migration # traffic can then use this config option and avoids the impact on the # management network. # # Possible values: # # * A valid IP address or hostname, else None. # # Related options: # # * ``live_migration_tunnelled``: The live_migration_inbound_addr value is # ignored if tunneling is enabled. # (string value) #live_migration_inbound_addr = # DEPRECATED: # Live migration target URI to use. # # Override the default libvirt live migration target URI (which is dependent # on virt_type). Any included "%s" is replaced with the migration target # hostname. # # If this option is set to None (which is the default), Nova will automatically # generate the `live_migration_uri` value based on only 4 supported `virt_type` # in following list: # # * 'kvm': 'qemu+tcp://%s/system' # * 'qemu': 'qemu+tcp://%s/system' # * 'xen': 'xenmigr://%s/system' # * 'parallels': 'parallels+tcp://%s/system' # # Related options: # # * ``live_migration_inbound_addr``: If ``live_migration_inbound_addr`` value # is not None and ``live_migration_tunnelled`` is False, the ip/hostname # address of target compute node is used instead of ``live_migration_uri`` as # the uri for live migration. # * ``live_migration_scheme``: If ``live_migration_uri`` is not set, the scheme # used for live migration is taken from ``live_migration_scheme`` instead. # (string value) # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # live_migration_uri is deprecated for removal in favor of two other options # that # allow to change live migration scheme and target URI: # ``live_migration_scheme`` # and ``live_migration_inbound_addr`` respectively. #live_migration_uri = # # URI scheme used for live migration. # # Override the default libvirt live migration scheme (which is dependent on # virt_type). If this option is set to None, nova will automatically choose a # sensible default based on the hypervisor. It is not recommended that you # change # this unless you are very sure that hypervisor supports a particular scheme. # # Related options: # # * ``virt_type``: This option is meaningful only when ``virt_type`` is set to # `kvm` or `qemu`. # * ``live_migration_uri``: If ``live_migration_uri`` value is not None, the # scheme used for live migration is taken from ``live_migration_uri`` instead. # (string value) #live_migration_scheme = # # Enable tunnelled migration. # # This option enables the tunnelled migration feature, where migration data is # transported over the libvirtd connection. If enabled, we use the # VIR_MIGRATE_TUNNELLED migration flag, avoiding the need to configure # the network to allow direct hypervisor to hypervisor communication. # If False, use the native transport. If not set, Nova will choose a # sensible default based on, for example the availability of native # encryption support in the hypervisor. Enabling this option will definitely # impact performance massively. # # Note that this option is NOT compatible with use of block migration. # # Related options: # # * ``live_migration_inbound_addr``: The live_migration_inbound_addr value is # ignored if tunneling is enabled. # (boolean value) #live_migration_tunnelled = false # # Maximum bandwidth(in MiB/s) to be used during migration. # # If set to 0, the hypervisor will choose a suitable default. Some hypervisors # do not support this feature and will return an error if bandwidth is not 0. # Please refer to the libvirt documentation for further details. # (integer value) #live_migration_bandwidth = 0 # # Maximum permitted downtime, in milliseconds, for live migration # switchover. # # Will be rounded up to a minimum of 100ms. You can increase this value # if you want to allow live-migrations to complete faster, or avoid # live-migration timeout errors by allowing the guest to be paused for # longer during the live-migration switch over. # # Related options: # # * live_migration_completion_timeout # (integer value) # Minimum value: 100 #live_migration_downtime = 500 # # Number of incremental steps to reach max downtime value. # # Will be rounded up to a minimum of 3 steps. # (integer value) # Minimum value: 3 #live_migration_downtime_steps = 10 # # Time to wait, in seconds, between each step increase of the migration # downtime. # # Minimum delay is 3 seconds. Value is per GiB of guest RAM + disk to be # transferred, with lower bound of a minimum of 2 GiB per device. # (integer value) # Minimum value: 3 #live_migration_downtime_delay = 75 # # Time to wait, in seconds, for migration to successfully complete transferring # data before aborting the operation. # # Value is per GiB of guest RAM + disk to be transferred, with lower bound of # a minimum of 2 GiB. Should usually be larger than downtime delay * downtime # steps. Set to 0 to disable timeouts. # # Related options: # # * live_migration_downtime # * live_migration_downtime_steps # * live_migration_downtime_delay # (integer value) # Note: This option can be changed without restarting. #live_migration_completion_timeout = 800 # DEPRECATED: # Time to wait, in seconds, for migration to make forward progress in # transferring data before aborting the operation. # # Set to 0 to disable timeouts. # # This is deprecated, and now disabled by default because we have found serious # bugs in this feature that caused false live-migration timeout failures. This # feature will be removed or replaced in a future release. # (integer value) # Note: This option can be changed without restarting. # This option is deprecated for removal. # Its value may be silently ignored in the future. # Reason: Serious bugs found in this feature. #live_migration_progress_timeout = 0 # # This option allows nova to switch an on-going live migration to post-copy # mode, i.e., switch the active VM to the one on the destination node before the # migration is complete, therefore ensuring an upper bound on the memory that # needs to be transferred. Post-copy requires libvirt>=1.3.3 and QEMU>=2.5.0. # # When permitted, post-copy mode will be automatically activated if a # live-migration memory copy iteration does not make percentage increase of at # least 10% over the last iteration. # # The live-migration force complete API also uses post-copy when permitted. If # post-copy mode is not available, force complete falls back to pausing the VM # to ensure the live-migration operation will complete. # # When using post-copy mode, if the source and destination hosts loose network # connectivity, the VM being live-migrated will need to be rebooted. For more # details, please see the Administration guide. # # Related options: # # * live_migration_permit_auto_converge # (boolean value) #live_migration_permit_post_copy = false # # This option allows nova to start live migration with auto converge on. # # Auto converge throttles down CPU if a progress of on-going live migration # is slow. Auto converge will only be used if this flag is set to True and # post copy is not permitted or post copy is unavailable due to the version # of libvirt and QEMU in use. # # Related options: # # * live_migration_permit_post_copy # (boolean value) #live_migration_permit_auto_converge = false # # Determine the snapshot image format when sending to the image service. # # If set, this decides what format is used when sending the snapshot to the # image service. # If not set, defaults to same type as source image. # # Possible values: # # * ``raw``: RAW disk format # * ``qcow2``: KVM default disk format # * ``vmdk``: VMWare default disk format # * ``vdi``: VirtualBox default disk format # * If not set, defaults to same type as source image. # (string value) # Possible values: # raw - # qcow2 - # vmdk - # vdi - #snapshot_image_format = # # Override the default disk prefix for the devices attached to an instance. # # If set, this is used to identify a free disk device name for a bus. # # Possible values: # # * Any prefix which will result in a valid disk device name like 'sda' or 'hda' # for example. This is only necessary if the device names differ to the # commonly known device name prefixes for a virtualization type such as: sd, # xvd, uvd, vd. # # Related options: # # * ``virt_type``: Influences which device type is used, which determines # the default disk prefix. # (string value) #disk_prefix = # Number of seconds to wait for instance to shut down after soft reboot request # is made. We fall back to hard reboot if instance does not shutdown within this # window. (integer value) #wait_soft_reboot_seconds = 120 # # Is used to set the CPU mode an instance should have. # # If virt_type="kvm|qemu", it will default to "host-model", otherwise it will # default to "none". # # Possible values: # # * ``host-model``: Clones the host CPU feature flags # * ``host-passthrough``: Use the host CPU model exactly # * ``custom``: Use a named CPU model # * ``none``: Don't set a specific CPU model. For instances with # ``virt_type`` as KVM/QEMU, the default CPU model from QEMU will be used, # which provides a basic set of CPU features that are compatible with most # hosts. # # Related options: # # * ``cpu_model``: This should be set ONLY when ``cpu_mode`` is set to # ``custom``. Otherwise, it would result in an error and the instance # launch will fail. # # (string value) # Possible values: # host-model - # host-passthrough - # custom - # none - #cpu_mode = # # Set the name of the libvirt CPU model the instance should use. # # Possible values: # # * The named CPU models listed in ``/usr/share/libvirt/cpu_map.xml`` # # Related options: # # * ``cpu_mode``: This should be set to ``custom`` ONLY when you want to # configure (via ``cpu_model``) a specific named CPU model. Otherwise, it # would result in an error and the instance launch will fail. # # * ``virt_type``: Only the virtualization types ``kvm`` and ``qemu`` use this. # (string value) #cpu_model = # # This allows specifying granular CPU feature flags when specifying CPU # models. For example, to explicitly specify the ``pcid`` # (Process-Context ID, an Intel processor feature) flag to the "IvyBridge" # virtual CPU model:: # # [libvirt] # cpu_mode = custom # cpu_model = IvyBridge # cpu_model_extra_flags = pcid # # Currently, the choice is restricted to a few options: ``pcid``, # ``ssbd``, ``virt-ssbd``, ``amd-ssbd``, and ``amd-no-ssb`` (the options # are case-insensitive, so ``PCID`` is also valid, for example). These # flags are now required to address the guest performance degradation as # a result of applying the "Meltdown" CVE fixes (``pcid``) and exposure # mitigation (``ssbd`` and related options) on affected CPU models. # # Note that when using this config attribute to set the 'PCID' and # related CPU flags, not all virtual (i.e. libvirt / QEMU) CPU models # need it: # # * The only virtual CPU models that include the 'PCID' capability are # Intel "Haswell", "Broadwell", and "Skylake" variants. # # * The libvirt / QEMU CPU models "Nehalem", "Westmere", "SandyBridge", # and "IvyBridge" will _not_ expose the 'PCID' capability by default, # even if the host CPUs by the same name include it. I.e. 'PCID' needs # to be explicitly specified when using the said virtual CPU models. # # For more information about ``ssbd`` and related options, # please refer to the following security updates: # # https://www.us-cert.gov/ncas/alerts/TA18-141A # # https://www.redhat.com/archives/libvir-list/2018-May/msg01562.html # # https://www.redhat.com/archives/libvir-list/2018-June/msg01111.html # # For now, the ``cpu_model_extra_flags`` config attribute is valid only in # combination with ``cpu_mode`` + ``cpu_model`` options. # # Besides ``custom``, the libvirt driver has two other CPU modes: The # default, ``host-model``, tells it to do the right thing with respect to # handling 'PCID' CPU flag for the guest -- *assuming* you are running # updated processor microcode, host and guest kernel, libvirt, and QEMU. # The other mode, ``host-passthrough``, checks if 'PCID' is available in # the hardware, and if so directly passes it through to the Nova guests. # Thus, in context of 'PCID', with either of these CPU modes # (``host-model`` or ``host-passthrough``), there is no need to use the # ``cpu_model_extra_flags``. # # Related options: # # * cpu_mode # * cpu_model # (list value) #cpu_model_extra_flags = # Location where libvirt driver will store snapshots before uploading them to # image service (string value) #snapshots_directory = $instances_path/snapshots # Location where the Xen hvmloader is kept (string value) #xen_hvmloader_path = /usr/lib/xen/boot/hvmloader # # Specific cache modes to use for different disk types. # # For example: file=directsync,block=none,network=writeback # # For local or direct-attached storage, it is recommended that you use # writethrough (default) mode, as it ensures data integrity and has acceptable # I/O performance for applications running in the guest, especially for read # operations. However, caching mode none is recommended for remote NFS storage, # because direct I/O operations (O_DIRECT) perform better than synchronous I/O # operations (with O_SYNC). Caching mode none effectively turns all guest I/O # operations into direct I/O operations on the host, which is the NFS client in # this environment. # # Possible cache modes: # # * default: Same as writethrough. # * none: With caching mode set to none, the host page cache is disabled, but # the disk write cache is enabled for the guest. In this mode, the write # performance in the guest is optimal because write operations bypass the host # page cache and go directly to the disk write cache. If the disk write cache # is battery-backed, or if the applications or storage stack in the guest # transfer data properly (either through fsync operations or file system # barriers), then data integrity can be ensured. However, because the host # page cache is disabled, the read performance in the guest would not be as # good as in the modes where the host page cache is enabled, such as # writethrough mode. Shareable disk devices, like for a multi-attachable block # storage volume, will have their cache mode set to 'none' regardless of # configuration. # * writethrough: writethrough mode is the default caching mode. With # caching set to writethrough mode, the host page cache is enabled, but the # disk write cache is disabled for the guest. Consequently, this caching mode # ensures data integrity even if the applications and storage stack in the # guest do not transfer data to permanent storage properly (either through # fsync operations or file system barriers). Because the host page cache is # enabled in this mode, the read performance for applications running in the # guest is generally better. However, the write performance might be reduced # because the disk write cache is disabled. # * writeback: With caching set to writeback mode, both the host page cache # and the disk write cache are enabled for the guest. Because of this, the # I/O performance for applications running in the guest is good, but the data # is not protected in a power failure. As a result, this caching mode is # recommended only for temporary data where potential data loss is not a # concern. # * directsync: Like "writethrough", but it bypasses the host page cache. # * unsafe: Caching mode of unsafe ignores cache transfer operations # completely. As its name implies, this caching mode should be used only for # temporary data where data loss is not a concern. This mode can be useful for # speeding up guest installations, but you should switch to another caching # mode in production environments. # (list value) #disk_cachemodes = # A path to a device that will be used as source of entropy on the host. # Permitted options are: /dev/random or /dev/hwrng (string value) #rng_dev_path = # For qemu or KVM guests, set this option to specify a default machine type per # host architecture. You can find a list of supported machine types in your # environment by checking the output of the "virsh capabilities"command. The # format of the value for this config option is host-arch=machine-type. For # example: x86_64=machinetype1,armv7l=machinetype2 (list value) #hw_machine_type = # The data source used to the populate the host "serial" UUID exposed to guest # in the virtual BIOS. (string value) # Possible values: # none - # os - # hardware - # auto - #sysinfo_serial = auto # A number of seconds to memory usage statistics period. Zero or negative value # mean to disable memory usage statistics. (integer value) #mem_stats_period_seconds = 10 # List of uid targets and ranges.Syntax is guest-uid:host-uid:countMaximum of 5 # allowed. (list value) #uid_maps = # List of guid targets and ranges.Syntax is guest-gid:host-gid:countMaximum of 5 # allowed. (list value) #gid_maps = # In a realtime host context vCPUs for guest will run in that scheduling # priority. Priority depends on the host kernel (usually 1-99) (integer value) #realtime_scheduler_priority = 1 # # This is a performance event list which could be used as monitor. These events # will be passed to libvirt domain xml while creating a new instances. # Then event statistics data can be collected from libvirt. The minimum # libvirt version is 2.0.0. For more information about `Performance monitoring # events`, refer https://libvirt.org/formatdomain.html#elementsPerf . # # Possible values: # * A string list. For example: ``enabled_perf_events = cmt, mbml, mbmt`` # The supported events list can be found in # https://libvirt.org/html/libvirt-libvirt-domain.html , # which you may need to search key words ``VIR_PERF_PARAM_*`` # (list value) #enabled_perf_events = # # VM Images format. # # If default is specified, then use_cow_images flag is used instead of this # one. # # Related options: # # * virt.use_cow_images # * images_volume_group # * [workarounds]/ensure_libvirt_rbd_instance_dir_cleanup # (string value) # Possible values: # raw - # flat - # qcow2 - # lvm - # rbd - # ploop - # default - #images_type = default # # LVM Volume Group that is used for VM images, when you specify images_type=lvm # # Related options: # # * images_type # (string value) #images_volume_group = # # Create sparse logical volumes (with virtualsize) if this flag is set to True. # (boolean value) #sparse_logical_volumes = false # The RADOS pool in which rbd volumes are stored (string value) #images_rbd_pool = rbd # Path to the ceph configuration file to use (string value) #images_rbd_ceph_conf = # # Discard option for nova managed disks. # # Requires: # # * Libvirt >= 1.0.6 # * Qemu >= 1.5 (raw format) # * Qemu >= 1.6 (qcow2 format) # (string value) # Possible values: # ignore - # unmap - #hw_disk_discard = # DEPRECATED: Allows image information files to be stored in non-standard # locations (string value) # This option is deprecated for removal since 14.0.0. # Its value may be silently ignored in the future. # Reason: Image info files are no longer used by the image cache #image_info_filename_pattern = $instances_path/$image_cache_subdirectory_name/%(image)s.info # Unused resized base images younger than this will not be removed (integer # value) #remove_unused_resized_minimum_age_seconds = 3600 # DEPRECATED: Write a checksum for files in _base to disk (boolean value) # This option is deprecated for removal since 14.0.0. # Its value may be silently ignored in the future. # Reason: The image cache no longer periodically calculates checksums of stored # images. Data integrity can be checked at the block or filesystem level. #checksum_base_images = false # DEPRECATED: How frequently to checksum base images (integer value) # This option is deprecated for removal since 14.0.0. # Its value may be silently ignored in the future. # Reason: The image cache no longer periodically calculates checksums of stored # images. Data integrity can be checked at the block or filesystem level. #checksum_interval_seconds = 3600 # # Method used to wipe ephemeral disks when they are deleted. Only takes effect # if LVM is set as backing storage. # # Possible values: # # * none - do not wipe deleted volumes # * zero - overwrite volumes with zeroes # * shred - overwrite volume repeatedly # # Related options: # # * images_type - must be set to ``lvm`` # * volume_clear_size # (string value) # Possible values: # none - # zero - # shred - #volume_clear = zero # # Size of area in MiB, counting from the beginning of the allocated volume, # that will be cleared using method set in ``volume_clear`` option. # # Possible values: # # * 0 - clear whole volume # * >0 - clear specified amount of MiB # # Related options: # # * images_type - must be set to ``lvm`` # * volume_clear - must be set and the value must be different than ``none`` # for this option to have any impact # (integer value) # Minimum value: 0 #volume_clear_size = 0 # # Enable snapshot compression for ``qcow2`` images. # # Note: you can set ``snapshot_image_format`` to ``qcow2`` to force all # snapshots to be in ``qcow2`` format, independently from their original image # type. # # Related options: # # * snapshot_image_format # (boolean value) #snapshot_compression = false # Use virtio for bridge interfaces with KVM/QEMU (boolean value) #use_virtio_for_bridges = true # # Use multipath connection of the iSCSI or FC volume # # Volumes can be connected in the LibVirt as multipath devices. This will # provide high availability and fault tolerance. # (boolean value) # Deprecated group/name - [libvirt]/iscsi_use_multipath #volume_use_multipath = false # # Number of times to scan given storage protocol to find volume. # (integer value) # Deprecated group/name - [libvirt]/num_iscsi_scan_tries #num_volume_scan_tries = 5 # # Number of times to rediscover AoE target to find volume. # # Nova provides support for block storage attaching to hosts via AOE (ATA over # Ethernet). This option allows the user to specify the maximum number of retry # attempts that can be made to discover the AoE device. # (integer value) #num_aoe_discover_tries = 3 # # The iSCSI transport iface to use to connect to target in case offload support # is desired. # # Default format is of the form . where # is one of (be2iscsi, bnx2i, cxgb3i, cxgb4i, qla4xxx, ocs) and # is the MAC address of the interface and can be generated via the # iscsiadm -m iface command. Do not confuse the iscsi_iface parameter to be # provided here with the actual transport name. # (string value) # Deprecated group/name - [libvirt]/iscsi_transport #iscsi_iface = # # Number of times to scan iSER target to find volume. # # iSER is a server network protocol that extends iSCSI protocol to use Remote # Direct Memory Access (RDMA). This option allows the user to specify the # maximum # number of scan attempts that can be made to find iSER volume. # (integer value) #num_iser_scan_tries = 5 # # Use multipath connection of the iSER volume. # # iSER volumes can be connected as multipath devices. This will provide high # availability and fault tolerance. # (boolean value) #iser_use_multipath = false # # The RADOS client name for accessing rbd(RADOS Block Devices) volumes. # # Libvirt will refer to this user when connecting and authenticating with # the Ceph RBD server. # (string value) #rbd_user = # # The libvirt UUID of the secret for the rbd_user volumes. # (string value) #rbd_secret_uuid = # # Directory where the NFS volume is mounted on the compute node. # The default is 'mnt' directory of the location where nova's Python module # is installed. # # NFS provides shared storage for the OpenStack Block Storage service. # # Possible values: # # * A string representing absolute path of mount point. # (string value) #nfs_mount_point_base = $state_path/mnt # # Mount options passed to the NFS client. See section of the nfs man page # for details. # # Mount options controls the way the filesystem is mounted and how the # NFS client behaves when accessing files on this mount point. # # Possible values: # # * Any string representing mount options separated by commas. # * Example string: vers=3,lookupcache=pos # (string value) #nfs_mount_options = # # Directory where the Quobyte volume is mounted on the compute node. # # Nova supports Quobyte volume driver that enables storing Block Storage # service volumes on a Quobyte storage back end. This Option specifies the # path of the directory where Quobyte volume is mounted. # # Possible values: # # * A string representing absolute path of mount point. # (string value) #quobyte_mount_point_base = $state_path/mnt # Path to a Quobyte Client configuration file. (string value) #quobyte_client_cfg = # # Directory where the SMBFS shares are mounted on the compute node. # (string value) #smbfs_mount_point_base = $state_path/mnt # # Mount options passed to the SMBFS client. # # Provide SMBFS options as a single string containing all parameters. # See mount.cifs man page for details. Note that the libvirt-qemu ``uid`` # and ``gid`` must be specified. # (string value) #smbfs_mount_options = # # libvirt's transport method for remote file operations. # # Because libvirt cannot use RPC to copy files over network to/from other # compute nodes, other method must be used for: # # * creating directory on remote host # * creating file on remote host # * removing file from remote host # * copying file to remote host # (string value) # Possible values: # ssh - # rsync - #remote_filesystem_transport = ssh # # Directory where the Virtuozzo Storage clusters are mounted on the compute # node. # # This option defines non-standard mountpoint for Vzstorage cluster. # # Related options: # # * vzstorage_mount_* group of parameters # (string value) #vzstorage_mount_point_base = $state_path/mnt # # Mount owner user name. # # This option defines the owner user of Vzstorage cluster mountpoint. # # Related options: # # * vzstorage_mount_* group of parameters # (string value) #vzstorage_mount_user = stack # # Mount owner group name. # # This option defines the owner group of Vzstorage cluster mountpoint. # # Related options: # # * vzstorage_mount_* group of parameters # (string value) #vzstorage_mount_group = qemu # # Mount access mode. # # This option defines the access bits of Vzstorage cluster mountpoint, # in the format similar to one of chmod(1) utility, like this: 0770. # It consists of one to four digits ranging from 0 to 7, with missing # lead digits assumed to be 0's. # # Related options: # # * vzstorage_mount_* group of parameters # (string value) #vzstorage_mount_perms = 0770 # # Path to vzstorage client log. # # This option defines the log of cluster operations, # it should include "%(cluster_name)s" template to separate # logs from multiple shares. # # Related options: # # * vzstorage_mount_opts may include more detailed logging options. # (string value) #vzstorage_log_path = /var/log/vstorage/%(cluster_name)s/nova.log.gz # # Path to the SSD cache file. # # You can attach an SSD drive to a client and configure the drive to store # a local cache of frequently accessed data. By having a local cache on a # client's SSD drive, you can increase the overall cluster performance by # up to 10 and more times. # WARNING! There is a lot of SSD models which are not server grade and # may loose arbitrary set of data changes on power loss. # Such SSDs should not be used in Vstorage and are dangerous as may lead # to data corruptions and inconsistencies. Please consult with the manual # on which SSD models are known to be safe or verify it using # vstorage-hwflush-check(1) utility. # # This option defines the path which should include "%(cluster_name)s" # template to separate caches from multiple shares. # # Related options: # # * vzstorage_mount_opts may include more detailed cache options. # (string value) #vzstorage_cache_path = # # Extra mount options for pstorage-mount # # For full description of them, see # https://static.openvz.org/vz-man/man1/pstorage-mount.1.gz.html # Format is a python string representation of arguments list, like: # "['-v', '-R', '500']" # Shouldn't include -c, -l, -C, -u, -g and -m as those have # explicit vzstorage_* options. # # Related options: # # * All other vzstorage_* options # (list value) #vzstorage_mount_opts = [matchmaker_redis] # # From oslo.messaging # # DEPRECATED: Host to locate redis. (string value) # This option is deprecated for removal. # Its value may be silently ignored in the future. # Reason: Replaced by [DEFAULT]/transport_url #host = 127.0.0.1 # DEPRECATED: Use this port to connect to redis host. (port value) # Minimum value: 0 # Maximum value: 65535 # This option is deprecated for removal. # Its value may be silently ignored in the future. # Reason: Replaced by [DEFAULT]/transport_url #port = 6379 # DEPRECATED: Password for Redis server (optional). (string value) # This option is deprecated for removal. # Its value may be silently ignored in the future. # Reason: Replaced by [DEFAULT]/transport_url #password = # DEPRECATED: List of Redis Sentinel hosts (fault tolerance mode), e.g., # [host:port, host1:port ... ] (list value) # This option is deprecated for removal. # Its value may be silently ignored in the future. # Reason: Replaced by [DEFAULT]/transport_url #sentinel_hosts = # Redis replica set name. (string value) #sentinel_group_name = oslo-messaging-zeromq # Time in ms to wait between connection attempts. (integer value) #wait_timeout = 2000 # Time in ms to wait before the transaction is killed. (integer value) #check_timeout = 20000 # Timeout in ms on blocking socket operations. (integer value) #socket_timeout = 10000 [metrics] # # Configuration options for metrics # # Options under this group allow to adjust how values assigned to metrics are # calculated. # # From nova.conf # # # When using metrics to weight the suitability of a host, you can use this # option # to change how the calculated weight influences the weight assigned to a host # as # follows: # # * >1.0: increases the effect of the metric on overall weight # * 1.0: no change to the calculated weight # * >0.0,<1.0: reduces the effect of the metric on overall weight # * 0.0: the metric value is ignored, and the value of the # 'weight_of_unavailable' option is returned instead # * >-1.0,<0.0: the effect is reduced and reversed # * -1.0: the effect is reversed # * <-1.0: the effect is increased proportionally and reversed # # This option is only used by the FilterScheduler and its subclasses; if you use # a different scheduler, this option has no effect. # # Possible values: # # * An integer or float value, where the value corresponds to the multipler # ratio for this weigher. # # Related options: # # * weight_of_unavailable # (floating point value) #weight_multiplier = 1.0 # # This setting specifies the metrics to be weighed and the relative ratios for # each metric. This should be a single string value, consisting of a series of # one or more 'name=ratio' pairs, separated by commas, where 'name' is the name # of the metric to be weighed, and 'ratio' is the relative weight for that # metric. # # Note that if the ratio is set to 0, the metric value is ignored, and instead # the weight will be set to the value of the 'weight_of_unavailable' option. # # As an example, let's consider the case where this option is set to: # # ``name1=1.0, name2=-1.3`` # # The final weight will be: # # ``(name1.value * 1.0) + (name2.value * -1.3)`` # # This option is only used by the FilterScheduler and its subclasses; if you use # a different scheduler, this option has no effect. # # Possible values: # # * A list of zero or more key/value pairs separated by commas, where the key is # a string representing the name of a metric and the value is a numeric weight # for that metric. If any value is set to 0, the value is ignored and the # weight will be set to the value of the 'weight_of_unavailable' option. # # Related options: # # * weight_of_unavailable # (list value) #weight_setting = # # This setting determines how any unavailable metrics are treated. If this # option # is set to True, any hosts for which a metric is unavailable will raise an # exception, so it is recommended to also use the MetricFilter to filter out # those hosts before weighing. # # This option is only used by the FilterScheduler and its subclasses; if you use # a different scheduler, this option has no effect. # # Possible values: # # * True or False, where False ensures any metric being unavailable for a host # will set the host weight to 'weight_of_unavailable'. # # Related options: # # * weight_of_unavailable # (boolean value) #required = true # # When any of the following conditions are met, this value will be used in place # of any actual metric value: # # * One of the metrics named in 'weight_setting' is not available for a host, # and the value of 'required' is False # * The ratio specified for a metric in 'weight_setting' is 0 # * The 'weight_multiplier' option is set to 0 # # This option is only used by the FilterScheduler and its subclasses; if you use # a different scheduler, this option has no effect. # # Possible values: # # * An integer or float value, where the value corresponds to the multipler # ratio for this weigher. # # Related options: # # * weight_setting # * required # * weight_multiplier # (floating point value) #weight_of_unavailable = -10000.0 [mks] # # Nova compute node uses WebMKS, a desktop sharing protocol to provide # instance console access to VM's created by VMware hypervisors. # # Related options: # Following options must be set to provide console access. # * mksproxy_base_url # * enabled # # From nova.conf # # # Location of MKS web console proxy # # The URL in the response points to a WebMKS proxy which # starts proxying between client and corresponding vCenter # server where instance runs. In order to use the web based # console access, WebMKS proxy should be installed and configured # # Possible values: # # * Must be a valid URL of the form:``http://host:port/`` or # ``https://host:port/`` # (uri value) #mksproxy_base_url = http://127.0.0.1:6090/ # # Enables graphical console access for virtual machines. # (boolean value) #enabled = false [neutron] # # Configuration options for neutron (network connectivity as a service). # # From nova.conf # # DEPRECATED: # This option specifies the URL for connecting to Neutron. # # Possible values: # # * Any valid URL that points to the Neutron API service is appropriate here. # This typically matches the URL returned for the 'network' service type # from the Keystone service catalog. # (uri value) # This option is deprecated for removal since 17.0.0. # Its value may be silently ignored in the future. # Reason: Endpoint lookup uses the service catalog via common keystoneauth1 # Adapter configuration options. In the current release, "url" will override # this behavior, but will be ignored and/or removed in a future release. To # achieve the same result, use the endpoint_override option instead. #url = http://127.0.0.1:9696 # # Default name for the Open vSwitch integration bridge. # # Specifies the name of an integration bridge interface used by OpenvSwitch. # This option is only used if Neutron does not specify the OVS bridge name in # port binding responses. # (string value) #ovs_bridge = br-int # # Default name for the floating IP pool. # # Specifies the name of floating IP pool used for allocating floating IPs. This # option is only used if Neutron does not specify the floating IP pool name in # port binding reponses. # (string value) #default_floating_pool = nova # # Integer value representing the number of seconds to wait before querying # Neutron for extensions. After this number of seconds the next time Nova # needs to create a resource in Neutron it will requery Neutron for the # extensions that it has loaded. Setting value to 0 will refresh the # extensions with no wait. # (integer value) # Minimum value: 0 #extension_sync_interval = 600 # # When set to True, this option indicates that Neutron will be used to proxy # metadata requests and resolve instance ids. Otherwise, the instance ID must be # passed to the metadata request in the 'X-Instance-ID' header. # # Related options: # # * metadata_proxy_shared_secret # (boolean value) #service_metadata_proxy = false # # This option holds the shared secret string used to validate proxy requests to # Neutron metadata requests. In order to be used, the # 'X-Metadata-Provider-Signature' header must be supplied in the request. # # Related options: # # * service_metadata_proxy # (string value) #metadata_proxy_shared_secret = # PEM encoded Certificate Authority to use when verifying HTTPs connections. # (string value) #cafile = # PEM encoded client certificate cert file (string value) #certfile = # PEM encoded client certificate key file (string value) #keyfile = # Verify HTTPS connections. (boolean value) #insecure = false # Timeout value for http requests (integer value) #timeout = # Authentication type to load (string value) # Deprecated group/name - [neutron]/auth_plugin #auth_type = # Config Section from which to load plugin specific options (string value) #auth_section = # Authentication URL (string value) #auth_url = # Scope for system operations (string value) #system_scope = # Domain ID to scope to (string value) #domain_id = # Domain name to scope to (string value) #domain_name = # Project ID to scope to (string value) #project_id = # Project name to scope to (string value) #project_name = # Domain ID containing project (string value) #project_domain_id = # Domain name containing project (string value) #project_domain_name = # Trust ID (string value) #trust_id = # Optional domain ID to use with v3 and v2 parameters. It will be used for both # the user and project domain in v3 and ignored in v2 authentication. (string # value) #default_domain_id = # Optional domain name to use with v3 API and v2 parameters. It will be used for # both the user and project domain in v3 and ignored in v2 authentication. # (string value) #default_domain_name = # User ID (string value) #user_id = # Username (string value) # Deprecated group/name - [neutron]/user_name #username = # User's domain id (string value) #user_domain_id = # User's domain name (string value) #user_domain_name = # User's password (string value) #password = # Tenant ID (string value) #tenant_id = # Tenant Name (string value) #tenant_name = # The default service_type for endpoint URL discovery. (string value) #service_type = network # The default service_name for endpoint URL discovery. (string value) #service_name = # List of interfaces, in order of preference, for endpoint URL. (list value) #valid_interfaces = internal,public # The default region_name for endpoint URL discovery. (string value) #region_name = # Always use this endpoint URL for requests for this client. NOTE: The # unversioned endpoint should be specified here; to request a particular API # version, use the `version`, `min-version`, and/or `max-version` options. # (string value) #endpoint_override = [notifications] # # Most of the actions in Nova which manipulate the system state generate # notifications which are posted to the messaging component (e.g. RabbitMQ) and # can be consumed by any service outside the OpenStack. More technical details # at https://docs.openstack.org/nova/latest/reference/notifications.html # # From nova.conf # # # If set, send compute.instance.update notifications on # instance state changes. # # Please refer to # https://docs.openstack.org/nova/latest/reference/notifications.html for # additional information on notifications. # # Possible values: # # * None - no notifications # * "vm_state" - notifications are sent with VM state transition information in # the ``old_state`` and ``state`` fields. The ``old_task_state`` and # ``new_task_state`` fields will be set to the current task_state of the # instance. # * "vm_and_task_state" - notifications are sent with VM and task state # transition information. # (string value) # Possible values: # - # vm_state - # vm_and_task_state - #notify_on_state_change = # Default notification level for outgoing notifications. (string value) # Possible values: # DEBUG - # INFO - # WARN - # ERROR - # CRITICAL - # Deprecated group/name - [DEFAULT]/default_notification_level #default_level = INFO # DEPRECATED: # Default publisher_id for outgoing notifications. If you consider routing # notifications using different publisher, change this value accordingly. # # Possible values: # # * Defaults to the current hostname of this host, but it can be any valid # oslo.messaging publisher_id # # Related options: # # * host - Hostname, FQDN or IP address of this host. # (string value) # This option is deprecated for removal since 17.0.0. # Its value may be silently ignored in the future. # Reason: # This option is only used when ``monkey_patch=True`` and # ``monkey_patch_modules`` is configured to specify the legacy notify_decorator. # Since the monkey_patch and monkey_patch_modules options are deprecated, this # option is also deprecated. #default_publisher_id = $host # # Specifies which notification format shall be used by nova. # # The default value is fine for most deployments and rarely needs to be changed. # This value can be set to 'versioned' once the infrastructure moves closer to # consuming the newer format of notifications. After this occurs, this option # will be removed. # # Note that notifications can be completely disabled by setting ``driver=noop`` # in the ``[oslo_messaging_notifications]`` group. # # Possible values: # * unversioned: Only the legacy unversioned notifications are emitted. # * versioned: Only the new versioned notifications are emitted. # * both: Both the legacy unversioned and the new versioned notifications are # emitted. (Default) # # The list of versioned notifications is visible in # https://docs.openstack.org/nova/latest/reference/notifications.html # (string value) # Possible values: # unversioned - # versioned - # both - #notification_format = both # # Specifies the topics for the versioned notifications issued by nova. # # The default value is fine for most deployments and rarely needs to be changed. # However, if you have a third-party service that consumes versioned # notifications, it might be worth getting a topic for that service. # Nova will send a message containing a versioned notification payload to each # topic queue in this list. # # The list of versioned notifications is visible in # https://docs.openstack.org/nova/latest/reference/notifications.html # (list value) #versioned_notifications_topics = versioned_notifications # # If enabled, include block device information in the versioned notification # payload. Sending block device information is disabled by default as providing # that information can incur some overhead on the system since the information # may need to be loaded from the database. # (boolean value) #bdms_in_notifications = false [osapi_v21] # # From nova.conf # # DEPRECATED: # This option is a string representing a regular expression (regex) that matches # the project_id as contained in URLs. If not set, it will match normal UUIDs # created by keystone. # # Possible values: # # * A string representing any legal regular expression # (string value) # This option is deprecated for removal since 13.0.0. # Its value may be silently ignored in the future. # Reason: # Recent versions of nova constrain project IDs to hexadecimal characters and # dashes. If your installation uses IDs outside of this range, you should use # this option to provide your own regex and give you time to migrate offending # projects to valid IDs before the next release. #project_id_regex = [oslo_concurrency] #pavlos lock_path = /var/lib/nova/tmp # # From oslo.concurrency # # Enables or disables inter-process locks. (boolean value) #disable_process_locking = false # Directory to use for lock files. For security, the specified directory should # only be writable by the user running the processes that need locking. Defaults # to environment variable OSLO_LOCK_PATH. If OSLO_LOCK_PATH is not set in the # environment, use the Python tempfile.gettempdir function to find a suitable # location. If external locks are used, a lock path must be set. (string value) #lock_path = /tmp [oslo_messaging_amqp] # # From oslo.messaging # # Name for the AMQP container. must be globally unique. Defaults to a generated # UUID (string value) #container_name = # Timeout for inactive connections (in seconds) (integer value) #idle_timeout = 0 # Debug: dump AMQP frames to stdout (boolean value) #trace = false # Attempt to connect via SSL. If no other ssl-related parameters are given, it # will use the system's CA-bundle to verify the server's certificate. (boolean # value) #ssl = false # CA certificate PEM file used to verify the server's certificate (string value) #ssl_ca_file = # Self-identifying certificate PEM file for client authentication (string value) #ssl_cert_file = # Private key PEM file used to sign ssl_cert_file certificate (optional) (string # value) #ssl_key_file = # Password for decrypting ssl_key_file (if encrypted) (string value) #ssl_key_password = # By default SSL checks that the name in the server's certificate matches the # hostname in the transport_url. In some configurations it may be preferable to # use the virtual hostname instead, for example if the server uses the Server # Name Indication TLS extension (rfc6066) to provide a certificate per virtual # host. Set ssl_verify_vhost to True if the server's SSL certificate uses the # virtual host name instead of the DNS name. (boolean value) #ssl_verify_vhost = false # DEPRECATED: Accept clients using either SSL or plain TCP (boolean value) # This option is deprecated for removal. # Its value may be silently ignored in the future. # Reason: Not applicable - not a SSL server #allow_insecure_clients = false # Space separated list of acceptable SASL mechanisms (string value) #sasl_mechanisms = # Path to directory that contains the SASL configuration (string value) #sasl_config_dir = # Name of configuration file (without .conf suffix) (string value) #sasl_config_name = # SASL realm to use if no realm present in username (string value) #sasl_default_realm = # DEPRECATED: User name for message broker authentication (string value) # This option is deprecated for removal. # Its value may be silently ignored in the future. # Reason: Should use configuration option transport_url to provide the username. #username = # DEPRECATED: Password for message broker authentication (string value) # This option is deprecated for removal. # Its value may be silently ignored in the future. # Reason: Should use configuration option transport_url to provide the password. #password = # Seconds to pause before attempting to re-connect. (integer value) # Minimum value: 1 #connection_retry_interval = 1 # Increase the connection_retry_interval by this many seconds after each # unsuccessful failover attempt. (integer value) # Minimum value: 0 #connection_retry_backoff = 2 # Maximum limit for connection_retry_interval + connection_retry_backoff # (integer value) # Minimum value: 1 #connection_retry_interval_max = 30 # Time to pause between re-connecting an AMQP 1.0 link that failed due to a # recoverable error. (integer value) # Minimum value: 1 #link_retry_delay = 10 # The maximum number of attempts to re-send a reply message which failed due to # a recoverable error. (integer value) # Minimum value: -1 #default_reply_retry = 0 # The deadline for an rpc reply message delivery. (integer value) # Minimum value: 5 #default_reply_timeout = 30 # The deadline for an rpc cast or call message delivery. Only used when caller # does not provide a timeout expiry. (integer value) # Minimum value: 5 #default_send_timeout = 30 # The deadline for a sent notification message delivery. Only used when caller # does not provide a timeout expiry. (integer value) # Minimum value: 5 #default_notify_timeout = 30 # The duration to schedule a purge of idle sender links. Detach link after # expiry. (integer value) # Minimum value: 1 #default_sender_link_timeout = 600 # Indicates the addressing mode used by the driver. # Permitted values: # 'legacy' - use legacy non-routable addressing # 'routable' - use routable addresses # 'dynamic' - use legacy addresses if the message bus does not support routing # otherwise use routable addressing (string value) #addressing_mode = dynamic # Enable virtual host support for those message buses that do not natively # support virtual hosting (such as qpidd). When set to true the virtual host # name will be added to all message bus addresses, effectively creating a # private 'subnet' per virtual host. Set to False if the message bus supports # virtual hosting using the 'hostname' field in the AMQP 1.0 Open performative # as the name of the virtual host. (boolean value) #pseudo_vhost = true # address prefix used when sending to a specific server (string value) #server_request_prefix = exclusive # address prefix used when broadcasting to all servers (string value) #broadcast_prefix = broadcast # address prefix when sending to any server in group (string value) #group_request_prefix = unicast # Address prefix for all generated RPC addresses (string value) #rpc_address_prefix = openstack.org/om/rpc # Address prefix for all generated Notification addresses (string value) #notify_address_prefix = openstack.org/om/notify # Appended to the address prefix when sending a fanout message. Used by the # message bus to identify fanout messages. (string value) #multicast_address = multicast # Appended to the address prefix when sending to a particular RPC/Notification # server. Used by the message bus to identify messages sent to a single # destination. (string value) #unicast_address = unicast # Appended to the address prefix when sending to a group of consumers. Used by # the message bus to identify messages that should be delivered in a round-robin # fashion across consumers. (string value) #anycast_address = anycast # Exchange name used in notification addresses. # Exchange name resolution precedence: # Target.exchange if set # else default_notification_exchange if set # else control_exchange if set # else 'notify' (string value) #default_notification_exchange = # Exchange name used in RPC addresses. # Exchange name resolution precedence: # Target.exchange if set # else default_rpc_exchange if set # else control_exchange if set # else 'rpc' (string value) #default_rpc_exchange = # Window size for incoming RPC Reply messages. (integer value) # Minimum value: 1 #reply_link_credit = 200 # Window size for incoming RPC Request messages (integer value) # Minimum value: 1 #rpc_server_credit = 100 # Window size for incoming Notification messages (integer value) # Minimum value: 1 #notify_server_credit = 100 # Send messages of this type pre-settled. # Pre-settled messages will not receive acknowledgement # from the peer. Note well: pre-settled messages may be # silently discarded if the delivery fails. # Permitted values: # 'rpc-call' - send RPC Calls pre-settled # 'rpc-reply'- send RPC Replies pre-settled # 'rpc-cast' - Send RPC Casts pre-settled # 'notify' - Send Notifications pre-settled # (multi valued) #pre_settled = rpc-cast #pre_settled = rpc-reply [oslo_messaging_kafka] # # From oslo.messaging # # DEPRECATED: Default Kafka broker Host (string value) # This option is deprecated for removal. # Its value may be silently ignored in the future. # Reason: Replaced by [DEFAULT]/transport_url #kafka_default_host = localhost # DEPRECATED: Default Kafka broker Port (port value) # Minimum value: 0 # Maximum value: 65535 # This option is deprecated for removal. # Its value may be silently ignored in the future. # Reason: Replaced by [DEFAULT]/transport_url #kafka_default_port = 9092 # Max fetch bytes of Kafka consumer (integer value) #kafka_max_fetch_bytes = 1048576 # Default timeout(s) for Kafka consumers (floating point value) #kafka_consumer_timeout = 1.0 # DEPRECATED: Pool Size for Kafka Consumers (integer value) # This option is deprecated for removal. # Its value may be silently ignored in the future. # Reason: Driver no longer uses connection pool. #pool_size = 10 # DEPRECATED: The pool size limit for connections expiration policy (integer # value) # This option is deprecated for removal. # Its value may be silently ignored in the future. # Reason: Driver no longer uses connection pool. #conn_pool_min_size = 2 # DEPRECATED: The time-to-live in sec of idle connections in the pool (integer # value) # This option is deprecated for removal. # Its value may be silently ignored in the future. # Reason: Driver no longer uses connection pool. #conn_pool_ttl = 1200 # Group id for Kafka consumer. Consumers in one group will coordinate message # consumption (string value) #consumer_group = oslo_messaging_consumer # Upper bound on the delay for KafkaProducer batching in seconds (floating point # value) #producer_batch_timeout = 0.0 # Size of batch for the producer async send (integer value) #producer_batch_size = 16384 [oslo_messaging_notifications] # # From oslo.messaging # # The Drivers(s) to handle sending notifications. Possible values are messaging, # messagingv2, routing, log, test, noop (multi valued) # Deprecated group/name - [DEFAULT]/notification_driver #driver = # A URL representing the messaging driver to use for notifications. If not set, # we fall back to the same configuration used for RPC. (string value) # Deprecated group/name - [DEFAULT]/notification_transport_url #transport_url = # AMQP topic used for OpenStack notifications. (list value) # Deprecated group/name - [rpc_notifier2]/topics # Deprecated group/name - [DEFAULT]/notification_topics #topics = notifications # The maximum number of attempts to re-send a notification message which failed # to be delivered due to a recoverable error. 0 - No retry, -1 - indefinite # (integer value) #retry = -1 [oslo_messaging_rabbit] # # From oslo.messaging # # Use durable queues in AMQP. (boolean value) # Deprecated group/name - [DEFAULT]/amqp_durable_queues # Deprecated group/name - [DEFAULT]/rabbit_durable_queues #amqp_durable_queues = false # Auto-delete queues in AMQP. (boolean value) #amqp_auto_delete = false # Enable SSL (boolean value) #ssl = # SSL version to use (valid only if SSL enabled). Valid values are TLSv1 and # SSLv23. SSLv2, SSLv3, TLSv1_1, and TLSv1_2 may be available on some # distributions. (string value) # Deprecated group/name - [oslo_messaging_rabbit]/kombu_ssl_version #ssl_version = # SSL key file (valid only if SSL enabled). (string value) # Deprecated group/name - [oslo_messaging_rabbit]/kombu_ssl_keyfile #ssl_key_file = # SSL cert file (valid only if SSL enabled). (string value) # Deprecated group/name - [oslo_messaging_rabbit]/kombu_ssl_certfile #ssl_cert_file = # SSL certification authority file (valid only if SSL enabled). (string value) # Deprecated group/name - [oslo_messaging_rabbit]/kombu_ssl_ca_certs #ssl_ca_file = # How long to wait before reconnecting in response to an AMQP consumer cancel # notification. (floating point value) #kombu_reconnect_delay = 1.0 # EXPERIMENTAL: Possible values are: gzip, bz2. If not set compression will not # be used. This option may not be available in future versions. (string value) #kombu_compression = # How long to wait a missing client before abandoning to send it its replies. # This value should not be longer than rpc_response_timeout. (integer value) # Deprecated group/name - [oslo_messaging_rabbit]/kombu_reconnect_timeout #kombu_missing_consumer_retry_timeout = 60 # Determines how the next RabbitMQ node is chosen in case the one we are # currently connected to becomes unavailable. Takes effect only if more than one # RabbitMQ node is provided in config. (string value) # Possible values: # round-robin - # shuffle - #kombu_failover_strategy = round-robin # DEPRECATED: The RabbitMQ broker address where a single node is used. (string # value) # This option is deprecated for removal. # Its value may be silently ignored in the future. # Reason: Replaced by [DEFAULT]/transport_url #rabbit_host = localhost # DEPRECATED: The RabbitMQ broker port where a single node is used. (port value) # Minimum value: 0 # Maximum value: 65535 # This option is deprecated for removal. # Its value may be silently ignored in the future. # Reason: Replaced by [DEFAULT]/transport_url #rabbit_port = 5672 # DEPRECATED: RabbitMQ HA cluster host:port pairs. (list value) # This option is deprecated for removal. # Its value may be silently ignored in the future. # Reason: Replaced by [DEFAULT]/transport_url #rabbit_hosts = $rabbit_host:$rabbit_port # DEPRECATED: The RabbitMQ userid. (string value) # This option is deprecated for removal. # Its value may be silently ignored in the future. # Reason: Replaced by [DEFAULT]/transport_url #rabbit_userid = guest # DEPRECATED: The RabbitMQ password. (string value) # This option is deprecated for removal. # Its value may be silently ignored in the future. # Reason: Replaced by [DEFAULT]/transport_url #rabbit_password = guest # The RabbitMQ login method. (string value) # Possible values: # PLAIN - # AMQPLAIN - # RABBIT-CR-DEMO - #rabbit_login_method = AMQPLAIN # DEPRECATED: The RabbitMQ virtual host. (string value) # This option is deprecated for removal. # Its value may be silently ignored in the future. # Reason: Replaced by [DEFAULT]/transport_url #rabbit_virtual_host = / # How frequently to retry connecting with RabbitMQ. (integer value) #rabbit_retry_interval = 1 # How long to backoff for between retries when connecting to RabbitMQ. (integer # value) #rabbit_retry_backoff = 2 # Maximum interval of RabbitMQ connection retries. Default is 30 seconds. # (integer value) #rabbit_interval_max = 30 # DEPRECATED: Maximum number of RabbitMQ connection retries. Default is 0 # (infinite retry count). (integer value) # This option is deprecated for removal. # Its value may be silently ignored in the future. #rabbit_max_retries = 0 # Try to use HA queues in RabbitMQ (x-ha-policy: all). If you change this # option, you must wipe the RabbitMQ database. In RabbitMQ 3.0, queue mirroring # is no longer controlled by the x-ha-policy argument when declaring a queue. If # you just want to make sure that all queues (except those with auto-generated # names) are mirrored across all nodes, run: "rabbitmqctl set_policy HA # '^(?!amq\.).*' '{"ha-mode": "all"}' " (boolean value) #rabbit_ha_queues = false # Positive integer representing duration in seconds for queue TTL (x-expires). # Queues which are unused for the duration of the TTL are automatically deleted. # The parameter affects only reply and fanout queues. (integer value) # Minimum value: 1 #rabbit_transient_queues_ttl = 1800 # Specifies the number of messages to prefetch. Setting to zero allows unlimited # messages. (integer value) #rabbit_qos_prefetch_count = 0 # Number of seconds after which the Rabbit broker is considered down if # heartbeat's keep-alive fails (0 disable the heartbeat). EXPERIMENTAL (integer # value) #heartbeat_timeout_threshold = 60 # How often times during the heartbeat_timeout_threshold we check the heartbeat. # (integer value) #heartbeat_rate = 2 # Deprecated, use rpc_backend=kombu+memory or rpc_backend=fake (boolean value) #fake_rabbit = false # Maximum number of channels to allow (integer value) #channel_max = # The maximum byte size for an AMQP frame (integer value) #frame_max = # How often to send heartbeats for consumer's connections (integer value) #heartbeat_interval = 3 # Arguments passed to ssl.wrap_socket (dict value) #ssl_options = # Set socket timeout in seconds for connection's socket (floating point value) #socket_timeout = 0.25 # Set TCP_USER_TIMEOUT in seconds for connection's socket (floating point value) #tcp_user_timeout = 0.25 # Set delay for reconnection to some host which has connection error (floating # point value) #host_connection_reconnect_delay = 0.25 # Connection factory implementation (string value) # Possible values: # new - # single - # read_write - #connection_factory = single # Maximum number of connections to keep queued. (integer value) #pool_max_size = 30 # Maximum number of connections to create above `pool_max_size`. (integer value) #pool_max_overflow = 0 # Default number of seconds to wait for a connections to available (integer # value) #pool_timeout = 30 # Lifetime of a connection (since creation) in seconds or None for no recycling. # Expired connections are closed on acquire. (integer value) #pool_recycle = 600 # Threshold at which inactive (since release) connections are considered stale # in seconds or None for no staleness. Stale connections are closed on acquire. # (integer value) #pool_stale = 60 # Default serialization mechanism for serializing/deserializing # outgoing/incoming messages (string value) # Possible values: # json - # msgpack - #default_serializer_type = json # Persist notification messages. (boolean value) #notification_persistence = false # Exchange name for sending notifications (string value) #default_notification_exchange = ${control_exchange}_notification # Max number of not acknowledged message which RabbitMQ can send to notification # listener. (integer value) #notification_listener_prefetch_count = 100 # Reconnecting retry count in case of connectivity problem during sending # notification, -1 means infinite retry. (integer value) #default_notification_retry_attempts = -1 # Reconnecting retry delay in case of connectivity problem during sending # notification message (floating point value) #notification_retry_delay = 0.25 # Time to live for rpc queues without consumers in seconds. (integer value) #rpc_queue_expiration = 60 # Exchange name for sending RPC messages (string value) #default_rpc_exchange = ${control_exchange}_rpc # Exchange name for receiving RPC replies (string value) #rpc_reply_exchange = ${control_exchange}_rpc_reply # Max number of not acknowledged message which RabbitMQ can send to rpc # listener. (integer value) #rpc_listener_prefetch_count = 100 # Max number of not acknowledged message which RabbitMQ can send to rpc reply # listener. (integer value) #rpc_reply_listener_prefetch_count = 100 # Reconnecting retry count in case of connectivity problem during sending reply. # -1 means infinite retry during rpc_timeout (integer value) #rpc_reply_retry_attempts = -1 # Reconnecting retry delay in case of connectivity problem during sending reply. # (floating point value) #rpc_reply_retry_delay = 0.25 # Reconnecting retry count in case of connectivity problem during sending RPC # message, -1 means infinite retry. If actual retry attempts in not 0 the rpc # request could be processed more than one time (integer value) #default_rpc_retry_attempts = -1 # Reconnecting retry delay in case of connectivity problem during sending RPC # message (floating point value) #rpc_retry_delay = 0.25 [oslo_messaging_zmq] # # From oslo.messaging # # ZeroMQ bind address. Should be a wildcard (*), an ethernet interface, or IP. # The "host" option should point or resolve to this address. (string value) #rpc_zmq_bind_address = * # MatchMaker driver. (string value) # Possible values: # redis - # sentinel - # dummy - #rpc_zmq_matchmaker = redis # Number of ZeroMQ contexts, defaults to 1. (integer value) #rpc_zmq_contexts = 1 # Maximum number of ingress messages to locally buffer per topic. Default is # unlimited. (integer value) #rpc_zmq_topic_backlog = # Directory for holding IPC sockets. (string value) #rpc_zmq_ipc_dir = /var/run/openstack # Name of this node. Must be a valid hostname, FQDN, or IP address. Must match # "host" option, if running Nova. (string value) #rpc_zmq_host = localhost # Number of seconds to wait before all pending messages will be sent after # closing a socket. The default value of -1 specifies an infinite linger period. # The value of 0 specifies no linger period. Pending messages shall be discarded # immediately when the socket is closed. Positive values specify an upper bound # for the linger period. (integer value) # Deprecated group/name - [DEFAULT]/rpc_cast_timeout #zmq_linger = -1 # The default number of seconds that poll should wait. Poll raises timeout # exception when timeout expired. (integer value) #rpc_poll_timeout = 1 # Expiration timeout in seconds of a name service record about existing target ( # < 0 means no timeout). (integer value) #zmq_target_expire = 300 # Update period in seconds of a name service record about existing target. # (integer value) #zmq_target_update = 180 # Use PUB/SUB pattern for fanout methods. PUB/SUB always uses proxy. (boolean # value) #use_pub_sub = false # Use ROUTER remote proxy. (boolean value) #use_router_proxy = false # This option makes direct connections dynamic or static. It makes sense only # with use_router_proxy=False which means to use direct connections for direct # message types (ignored otherwise). (boolean value) #use_dynamic_connections = false # How many additional connections to a host will be made for failover reasons. # This option is actual only in dynamic connections mode. (integer value) #zmq_failover_connections = 2 # Minimal port number for random ports range. (port value) # Minimum value: 0 # Maximum value: 65535 #rpc_zmq_min_port = 49153 # Maximal port number for random ports range. (integer value) # Minimum value: 1 # Maximum value: 65536 #rpc_zmq_max_port = 65536 # Number of retries to find free port number before fail with ZMQBindError. # (integer value) #rpc_zmq_bind_port_retries = 100 # Default serialization mechanism for serializing/deserializing # outgoing/incoming messages (string value) # Possible values: # json - # msgpack - #rpc_zmq_serialization = json # This option configures round-robin mode in zmq socket. True means not keeping # a queue when server side disconnects. False means to keep queue and messages # even if server is disconnected, when the server appears we send all # accumulated messages to it. (boolean value) #zmq_immediate = true # Enable/disable TCP keepalive (KA) mechanism. The default value of -1 (or any # other negative value) means to skip any overrides and leave it to OS default; # 0 and 1 (or any other positive value) mean to disable and enable the option # respectively. (integer value) #zmq_tcp_keepalive = -1 # The duration between two keepalive transmissions in idle condition. The unit # is platform dependent, for example, seconds in Linux, milliseconds in Windows # etc. The default value of -1 (or any other negative value and 0) means to skip # any overrides and leave it to OS default. (integer value) #zmq_tcp_keepalive_idle = -1 # The number of retransmissions to be carried out before declaring that remote # end is not available. The default value of -1 (or any other negative value and # 0) means to skip any overrides and leave it to OS default. (integer value) #zmq_tcp_keepalive_cnt = -1 # The duration between two successive keepalive retransmissions, if # acknowledgement to the previous keepalive transmission is not received. The # unit is platform dependent, for example, seconds in Linux, milliseconds in # Windows etc. The default value of -1 (or any other negative value and 0) means # to skip any overrides and leave it to OS default. (integer value) #zmq_tcp_keepalive_intvl = -1 # Maximum number of (green) threads to work concurrently. (integer value) #rpc_thread_pool_size = 100 # Expiration timeout in seconds of a sent/received message after which it is not # tracked anymore by a client/server. (integer value) #rpc_message_ttl = 300 # Wait for message acknowledgements from receivers. This mechanism works only # via proxy without PUB/SUB. (boolean value) #rpc_use_acks = false # Number of seconds to wait for an ack from a cast/call. After each retry # attempt this timeout is multiplied by some specified multiplier. (integer # value) #rpc_ack_timeout_base = 15 # Number to multiply base ack timeout by after each retry attempt. (integer # value) #rpc_ack_timeout_multiplier = 2 # Default number of message sending attempts in case of any problems occurred: # positive value N means at most N retries, 0 means no retries, None or -1 (or # any other negative values) mean to retry forever. This option is used only if # acknowledgments are enabled. (integer value) #rpc_retry_attempts = 3 # List of publisher hosts SubConsumer can subscribe on. This option has higher # priority then the default publishers list taken from the matchmaker. (list # value) #subscribe_on = [oslo_middleware] # # From oslo.middleware # # The maximum body size for each request, in bytes. (integer value) # Deprecated group/name - [DEFAULT]/osapi_max_request_body_size # Deprecated group/name - [DEFAULT]/max_request_body_size #max_request_body_size = 114688 # DEPRECATED: The HTTP Header that will be used to determine what the original # request protocol scheme was, even if it was hidden by a SSL termination proxy. # (string value) # This option is deprecated for removal. # Its value may be silently ignored in the future. #secure_proxy_ssl_header = X-Forwarded-Proto # Whether the application is behind a proxy or not. This determines if the # middleware should parse the headers or not. (boolean value) #enable_proxy_headers_parsing = false [oslo_policy] # # From oslo.policy # # This option controls whether or not to enforce scope when evaluating policies. # If ``True``, the scope of the token used in the request is compared to the # ``scope_types`` of the policy being enforced. If the scopes do not match, an # ``InvalidScope`` exception will be raised. If ``False``, a message will be # logged informing operators that policies are being invoked with mismatching # scope. (boolean value) #enforce_scope = false # The file that defines policies. (string value) #policy_file = policy.json # Default rule. Enforced when a requested rule is not found. (string value) #policy_default_rule = default # Directories where policy configuration files are stored. They can be relative # to any directory in the search path defined by the config_dir option, or # absolute paths. The file defined by policy_file must exist for these # directories to be searched. Missing or empty directories are ignored. (multi # valued) #policy_dirs = policy.d # Content Type to send and receive data for REST based policy check (string # value) # Possible values: # application/x-www-form-urlencoded - # application/json - #remote_content_type = application/x-www-form-urlencoded # server identity verification for REST based policy check (boolean value) #remote_ssl_verify_server_crt = false # Absolute path to ca cert file for REST based policy check (string value) #remote_ssl_ca_crt_file = # Absolute path to client cert for REST based policy check (string value) #remote_ssl_client_crt_file = # Absolute path client key file REST based policy check (string value) #remote_ssl_client_key_file = [pci] # # From nova.conf # # # An alias for a PCI passthrough device requirement. # # This allows users to specify the alias in the extra specs for a flavor, # without # needing to repeat all the PCI property requirements. # # Possible Values: # # * A list of JSON values which describe the aliases. For example:: # # alias = { # "name": "QuickAssist", # "product_id": "0443", # "vendor_id": "8086", # "device_type": "type-PCI", # "numa_policy": "required" # } # # This defines an alias for the Intel QuickAssist card. (multi valued). Valid # key values are : # # ``name`` # Name of the PCI alias. # # ``product_id`` # Product ID of the device in hexadecimal. # # ``vendor_id`` # Vendor ID of the device in hexadecimal. # # ``device_type`` # Type of PCI device. Valid values are: ``type-PCI``, ``type-PF`` and # ``type-VF``. # # ``numa_policy`` # Required NUMA affinity of device. Valid values are: ``legacy``, # ``preferred`` and ``required``. # (multi valued) # Deprecated group/name - [DEFAULT]/pci_alias #alias = # # White list of PCI devices available to VMs. # # Possible values: # # * A JSON dictionary which describe a whitelisted PCI device. It should take # the following format: # # ["vendor_id": "",] ["product_id": "",] # ["address": "[[[[]:]]:][][.[]]" | # "devname": "",] # {"": "",} # # Where '[' indicates zero or one occurrences, '{' indicates zero or multiple # occurrences, and '|' mutually exclusive options. Note that any missing # fields are automatically wildcarded. # # Valid key values are : # # * "vendor_id": Vendor ID of the device in hexadecimal. # * "product_id": Product ID of the device in hexadecimal. # * "address": PCI address of the device. # * "devname": Device name of the device (for e.g. interface name). Not all # PCI devices have a name. # * "": Additional and used for matching PCI devices. # Supported : "physical_network". # # The address key supports traditional glob style and regular expression # syntax. Valid examples are: # # passthrough_whitelist = {"devname":"eth0", # "physical_network":"physnet"} # passthrough_whitelist = {"address":"*:0a:00.*"} # passthrough_whitelist = {"address":":0a:00.", # "physical_network":"physnet1"} # passthrough_whitelist = {"vendor_id":"1137", # "product_id":"0071"} # passthrough_whitelist = {"vendor_id":"1137", # "product_id":"0071", # "address": "0000:0a:00.1", # "physical_network":"physnet1"} # passthrough_whitelist = {"address":{"domain": ".*", # "bus": "02", "slot": "01", # "function": "[2-7]"}, # "physical_network":"physnet1"} # passthrough_whitelist = {"address":{"domain": ".*", # "bus": "02", "slot": "0[1-2]", # "function": ".*"}, # "physical_network":"physnet1"} # # The following are invalid, as they specify mutually exclusive options: # # passthrough_whitelist = {"devname":"eth0", # "physical_network":"physnet", # "address":"*:0a:00.*"} # # * A JSON list of JSON dictionaries corresponding to the above format. For # example: # # passthrough_whitelist = [{"product_id":"0001", "vendor_id":"8086"}, # {"product_id":"0002", "vendor_id":"8086"}] # (multi valued) # Deprecated group/name - [DEFAULT]/pci_passthrough_whitelist #passthrough_whitelist = [placement] # pavlos --start #os_region_name = openstack <-- i removed this one os_region_name = RegionOne project_domain_name = Default project_name = service auth_type = password user_domain_name = Default auth_url = http://controller/identity/v3 #auth_url = http://controller:5000/v3 #auth_url = http://192.168.40.184/identity username = placement password = linux # pavlos --end # # From nova.conf # # DEPRECATED: # Region name of this node. This is used when picking the URL in the service # catalog. # # Possible values: # # * Any string representing region name # (string value) # This option is deprecated for removal since 17.0.0. # Its value may be silently ignored in the future. # Reason: Endpoint lookup uses the service catalog via common keystoneauth1 # Adapter configuration options. Use the region_name option instead. #os_region_name = # DEPRECATED: # Endpoint interface for this node. This is used when picking the URL in the # service catalog. # (string value) # This option is deprecated for removal since 17.0.0. # Its value may be silently ignored in the future. # Reason: Endpoint lookup uses the service catalog via common keystoneauth1 # Adapter configuration options. Use the valid_interfaces option instead. #os_interface = # # If True, when limiting allocation candidate results, the results will be # a random sampling of the full result set. If False, allocation candidates # are returned in a deterministic but undefined order. That is, all things # being equal, two requests for allocation candidates will return the same # results in the same order; but no guarantees are made as to how that order # is determined. # (boolean value) #randomize_allocation_candidates = false # PEM encoded Certificate Authority to use when verifying HTTPs connections. # (string value) #cafile = # PEM encoded client certificate cert file (string value) #certfile = # PEM encoded client certificate key file (string value) #keyfile = # Verify HTTPS connections. (boolean value) #insecure = false # Timeout value for http requests (integer value) #timeout = # Authentication type to load (string value) # Deprecated group/name - [placement]/auth_plugin #auth_type = # Config Section from which to load plugin specific options (string value) #auth_section = # Authentication URL (string value) #auth_url = # Scope for system operations (string value) #system_scope = # Domain ID to scope to (string value) #domain_id = # Domain name to scope to (string value) #domain_name = # Project ID to scope to (string value) #project_id = # Project name to scope to (string value) #project_name = # Domain ID containing project (string value) #project_domain_id = # Domain name containing project (string value) #project_domain_name = # Trust ID (string value) #trust_id = # Optional domain ID to use with v3 and v2 parameters. It will be used for both # the user and project domain in v3 and ignored in v2 authentication. (string # value) #default_domain_id = # Optional domain name to use with v3 API and v2 parameters. It will be used for # both the user and project domain in v3 and ignored in v2 authentication. # (string value) #default_domain_name = # User ID (string value) #user_id = # Username (string value) # Deprecated group/name - [placement]/user_name #username = # User's domain id (string value) #user_domain_id = # User's domain name (string value) #user_domain_name = # User's password (string value) #password = # Tenant ID (string value) #tenant_id = # Tenant Name (string value) #tenant_name = # The default service_type for endpoint URL discovery. (string value) #service_type = placement # The default service_name for endpoint URL discovery. (string value) #service_name = # List of interfaces, in order of preference, for endpoint URL. (list value) # Deprecated group/name - [placement]/os_interface #valid_interfaces = internal,public # The default region_name for endpoint URL discovery. (string value) # Deprecated group/name - [placement]/os_region_name #region_name = # Always use this endpoint URL for requests for this client. NOTE: The # unversioned endpoint should be specified here; to request a particular API # version, use the `version`, `min-version`, and/or `max-version` options. # (string value) #endpoint_override = [quota] # # Quota options allow to manage quotas in openstack deployment. # # From nova.conf # # # The number of instances allowed per project. # # Possible Values # # * A positive integer or 0. # * -1 to disable the quota. # (integer value) # Minimum value: -1 # Deprecated group/name - [DEFAULT]/quota_instances #instances = 10 # # The number of instance cores or vCPUs allowed per project. # # Possible values: # # * A positive integer or 0. # * -1 to disable the quota. # (integer value) # Minimum value: -1 # Deprecated group/name - [DEFAULT]/quota_cores #cores = 20 # # The number of megabytes of instance RAM allowed per project. # # Possible values: # # * A positive integer or 0. # * -1 to disable the quota. # (integer value) # Minimum value: -1 # Deprecated group/name - [DEFAULT]/quota_ram #ram = 51200 # DEPRECATED: # The number of floating IPs allowed per project. # # Floating IPs are not allocated to instances by default. Users need to select # them from the pool configured by the OpenStack administrator to attach to # their # instances. # # Possible values: # # * A positive integer or 0. # * -1 to disable the quota. # (integer value) # Minimum value: -1 # Deprecated group/name - [DEFAULT]/quota_floating_ips # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #floating_ips = 10 # DEPRECATED: # The number of fixed IPs allowed per project. # # Unlike floating IPs, fixed IPs are allocated dynamically by the network # component when instances boot up. This quota value should be at least the # number of instances allowed # # Possible values: # # * A positive integer or 0. # * -1 to disable the quota. # (integer value) # Minimum value: -1 # Deprecated group/name - [DEFAULT]/quota_fixed_ips # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #fixed_ips = -1 # # The number of metadata items allowed per instance. # # Users can associate metadata with an instance during instance creation. This # metadata takes the form of key-value pairs. # # Possible values: # # * A positive integer or 0. # * -1 to disable the quota. # (integer value) # Minimum value: -1 # Deprecated group/name - [DEFAULT]/quota_metadata_items #metadata_items = 128 # # The number of injected files allowed. # # File injection allows users to customize the personality of an instance by # injecting data into it upon boot. Only text file injection is permitted: # binary # or ZIP files are not accepted. During file injection, any existing files that # match specified files are renamed to include ``.bak`` extension appended with # a # timestamp. # # Possible values: # # * A positive integer or 0. # * -1 to disable the quota. # (integer value) # Minimum value: -1 # Deprecated group/name - [DEFAULT]/quota_injected_files #injected_files = 5 # # The number of bytes allowed per injected file. # # Possible values: # # * A positive integer or 0. # * -1 to disable the quota. # (integer value) # Minimum value: -1 # Deprecated group/name - [DEFAULT]/quota_injected_file_content_bytes #injected_file_content_bytes = 10240 # # The maximum allowed injected file path length. # # Possible values: # # * A positive integer or 0. # * -1 to disable the quota. # (integer value) # Minimum value: -1 # Deprecated group/name - [DEFAULT]/quota_injected_file_path_length #injected_file_path_length = 255 # DEPRECATED: # The number of security groups per project. # # Possible values: # # * A positive integer or 0. # * -1 to disable the quota. # (integer value) # Minimum value: -1 # Deprecated group/name - [DEFAULT]/quota_security_groups # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #security_groups = 10 # DEPRECATED: # The number of security rules per security group. # # The associated rules in each security group control the traffic to instances # in # the group. # # Possible values: # # * A positive integer or 0. # * -1 to disable the quota. # (integer value) # Minimum value: -1 # Deprecated group/name - [DEFAULT]/quota_security_group_rules # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # nova-network is deprecated, as are any related configuration options. #security_group_rules = 20 # # The maximum number of key pairs allowed per user. # # Users can create at least one key pair for each project and use the key pair # for multiple instances that belong to that project. # # Possible values: # # * A positive integer or 0. # * -1 to disable the quota. # (integer value) # Minimum value: -1 # Deprecated group/name - [DEFAULT]/quota_key_pairs #key_pairs = 100 # # The maxiumum number of server groups per project. # # Server groups are used to control the affinity and anti-affinity scheduling # policy for a group of servers or instances. Reducing the quota will not affect # any existing group, but new servers will not be allowed into groups that have # become over quota. # # Possible values: # # * A positive integer or 0. # * -1 to disable the quota. # (integer value) # Minimum value: -1 # Deprecated group/name - [DEFAULT]/quota_server_groups #server_groups = 10 # # The maximum number of servers per server group. # # Possible values: # # * A positive integer or 0. # * -1 to disable the quota. # (integer value) # Minimum value: -1 # Deprecated group/name - [DEFAULT]/quota_server_group_members #server_group_members = 10 # # The number of seconds until a reservation expires. # # This quota represents the time period for invalidating quota reservations. # (integer value) #reservation_expire = 86400 # # The count of reservations until usage is refreshed. # # This defaults to 0 (off) to avoid additional load but it is useful to turn on # to help keep quota usage up-to-date and reduce the impact of out of sync usage # issues. # (integer value) # Minimum value: 0 #until_refresh = 0 # # The number of seconds between subsequent usage refreshes. # # This defaults to 0 (off) to avoid additional load but it is useful to turn on # to help keep quota usage up-to-date and reduce the impact of out of sync usage # issues. Note that quotas are not updated on a periodic task, they will update # on a new reservation if max_age has passed since the last reservation. # (integer value) # Minimum value: 0 #max_age = 0 # DEPRECATED: # The quota enforcer driver. # # Provides abstraction for quota checks. Users can configure a specific # driver to use for quota checks. # # Possible values: # # * nova.quota.DbQuotaDriver (default) or any string representing fully # qualified class name. # (string value) # Deprecated group/name - [DEFAULT]/quota_driver # This option is deprecated for removal since 14.0.0. # Its value may be silently ignored in the future. #driver = nova.quota.DbQuotaDriver # # Recheck quota after resource creation to prevent allowing quota to be # exceeded. # # This defaults to True (recheck quota after resource creation) but can be set # to # False to avoid additional load if allowing quota to be exceeded because of # racing requests is considered acceptable. For example, when set to False, if a # user makes highly parallel REST API requests to create servers, it will be # possible for them to create more servers than their allowed quota during the # race. If their quota is 10 servers, they might be able to create 50 during the # burst. After the burst, they will not be able to create any more servers but # they will be able to keep their 50 servers until they delete them. # # The initial quota check is done before resources are created, so if multiple # parallel requests arrive at the same time, all could pass the quota check and # create resources, potentially exceeding quota. When recheck_quota is True, # quota will be checked a second time after resources have been created and if # the resource is over quota, it will be deleted and OverQuota will be raised, # usually resulting in a 403 response to the REST API user. This makes it # impossible for a user to exceed their quota with the caveat that it will, # however, be possible for a REST API user to be rejected with a 403 response in # the event of a collision close to reaching their quota limit, even if the user # has enough quota available when they made the request. # (boolean value) #recheck_quota = true [rdp] # # Options under this group enable and configure Remote Desktop Protocol ( # RDP) related features. # # This group is only relevant to Hyper-V users. # # From nova.conf # # # Enable Remote Desktop Protocol (RDP) related features. # # Hyper-V, unlike the majority of the hypervisors employed on Nova compute # nodes, uses RDP instead of VNC and SPICE as a desktop sharing protocol to # provide instance console access. This option enables RDP for graphical # console access for virtual machines created by Hyper-V. # # **Note:** RDP should only be enabled on compute nodes that support the Hyper-V # virtualization platform. # # Related options: # # * ``compute_driver``: Must be hyperv. # # (boolean value) #enabled = false # # The URL an end user would use to connect to the RDP HTML5 console proxy. # The console proxy service is called with this token-embedded URL and # establishes the connection to the proper instance. # # An RDP HTML5 console proxy service will need to be configured to listen on the # address configured here. Typically the console proxy service would be run on a # controller node. The localhost address used as default would only work in a # single node environment i.e. devstack. # # An RDP HTML5 proxy allows a user to access via the web the text or graphical # console of any Windows server or workstation using RDP. RDP HTML5 console # proxy services include FreeRDP, wsgate. # See https://github.com/FreeRDP/FreeRDP-WebConnect # # Possible values: # # * ://:/ # # The scheme must be identical to the scheme configured for the RDP HTML5 # console proxy service. It is ``http`` or ``https``. # # The IP address must be identical to the address on which the RDP HTML5 # console proxy service is listening. # # The port must be identical to the port on which the RDP HTML5 console proxy # service is listening. # # Related options: # # * ``rdp.enabled``: Must be set to ``True`` for ``html5_proxy_base_url`` to be # effective. # (uri value) #html5_proxy_base_url = http://127.0.0.1:6083/ [remote_debug] # # From nova.conf # # # Debug host (IP or name) to connect to. This command line parameter is used # when # you want to connect to a nova service via a debugger running on a different # host. # # Note that using the remote debug option changes how Nova uses the eventlet # library to support async IO. This could result in failures that do not occur # under normal operation. Use at your own risk. # # Possible Values: # # * IP address of a remote host as a command line parameter # to a nova service. For Example: # # /usr/local/bin/nova-compute --config-file /etc/nova/nova.conf # --remote_debug-host # (unknown value) #host = # # Debug port to connect to. This command line parameter allows you to specify # the port you want to use to connect to a nova service via a debugger running # on different host. # # Note that using the remote debug option changes how Nova uses the eventlet # library to support async IO. This could result in failures that do not occur # under normal operation. Use at your own risk. # # Possible Values: # # * Port number you want to use as a command line parameter # to a nova service. For Example: # # /usr/local/bin/nova-compute --config-file /etc/nova/nova.conf # --remote_debug-host # --remote_debug-port it's listening on>. # (port value) # Minimum value: 0 # Maximum value: 65535 #port = [scheduler] # # From nova.conf # # # The scheduler host manager to use. # # The host manager manages the in-memory picture of the hosts that the scheduler # uses. The options values are chosen from the entry points under the namespace # 'nova.scheduler.host_manager' in 'setup.cfg'. # # NOTE: The "ironic_host_manager" option is deprecated as of the 17.0.0 Queens # release. # (string value) # Possible values: # host_manager - # ironic_host_manager - # Deprecated group/name - [DEFAULT]/scheduler_host_manager #host_manager = host_manager # # The class of the driver used by the scheduler. This should be chosen from one # of the entrypoints under the namespace 'nova.scheduler.driver' of file # 'setup.cfg'. If nothing is specified in this option, the 'filter_scheduler' is # used. # # Other options are: # # * 'caching_scheduler' which aggressively caches the system state for better # individual scheduler performance at the risk of more retries when running # multiple schedulers. [DEPRECATED] # * 'chance_scheduler' which simply picks a host at random. [DEPRECATED] # * 'fake_scheduler' which is used for testing. # # Possible values: # # * Any of the drivers included in Nova: # ** filter_scheduler # ** caching_scheduler # ** chance_scheduler # ** fake_scheduler # * You may also set this to the entry point name of a custom scheduler driver, # but you will be responsible for creating and maintaining it in your # setup.cfg # file. # (string value) # Deprecated group/name - [DEFAULT]/scheduler_driver #driver = filter_scheduler # # Periodic task interval. # # This value controls how often (in seconds) to run periodic tasks in the # scheduler. The specific tasks that are run for each period are determined by # the particular scheduler being used. # # If this is larger than the nova-service 'service_down_time' setting, Nova may # report the scheduler service as down. This is because the scheduler driver is # responsible for sending a heartbeat and it will only do that as often as this # option allows. As each scheduler can work a little differently than the # others, # be sure to test this with your selected scheduler. # # Possible values: # # * An integer, where the integer corresponds to periodic task interval in # seconds. 0 uses the default interval (60 seconds). A negative value disables # periodic tasks. # # Related options: # # * ``nova-service service_down_time`` # (integer value) # Deprecated group/name - [DEFAULT]/scheduler_driver_task_period #periodic_task_interval = 60 # # This is the maximum number of attempts that will be made for a given instance # build/move operation. It limits the number of alternate hosts returned by the # scheduler. When that list of hosts is exhausted, a MaxRetriesExceeded # exception is raised and the instance is set to an error state. # # Possible values: # # * A positive integer, where the integer corresponds to the max number of # attempts that can be made when building or moving an instance. # (integer value) # Minimum value: 1 # Deprecated group/name - [DEFAULT]/scheduler_max_attempts #max_attempts = 3 # # Periodic task interval. # # This value controls how often (in seconds) the scheduler should attempt # to discover new hosts that have been added to cells. If negative (the # default), no automatic discovery will occur. # # Deployments where compute nodes come and go frequently may want this # enabled, where others may prefer to manually discover hosts when one # is added to avoid any overhead from constantly checking. If enabled, # every time this runs, we will select any unmapped hosts out of each # cell database on every run. # (integer value) # Minimum value: -1 #discover_hosts_in_cells_interval = -1 # # This setting determines the maximum limit on results received from the # placement service during a scheduling operation. It effectively limits # the number of hosts that may be considered for scheduling requests that # match a large number of candidates. # # A value of 1 (the minimum) will effectively defer scheduling to the placement # service strictly on "will it fit" grounds. A higher value will put an upper # cap on the number of results the scheduler will consider during the filtering # and weighing process. Large deployments may need to set this lower than the # total number of hosts available to limit memory consumption, network traffic, # etc. of the scheduler. # # This option is only used by the FilterScheduler; if you use a different # scheduler, this option has no effect. # (integer value) # Minimum value: 1 #max_placement_results = 1000 [serial_console] # # The serial console feature allows you to connect to a guest in case a # graphical console like VNC, RDP or SPICE is not available. This is only # currently supported for the libvirt, Ironic and hyper-v drivers. # # From nova.conf # # # Enable the serial console feature. # # In order to use this feature, the service ``nova-serialproxy`` needs to run. # This service is typically executed on the controller node. # (boolean value) #enabled = false # # A range of TCP ports a guest can use for its backend. # # Each instance which gets created will use one port out of this range. If the # range is not big enough to provide another port for an new instance, this # instance won't get launched. # # Possible values: # # * Each string which passes the regex ``\d+:\d+`` For example ``10000:20000``. # Be sure that the first port number is lower than the second port number # and that both are in range from 0 to 65535. # (string value) #port_range = 10000:20000 # # The URL an end user would use to connect to the ``nova-serialproxy`` service. # # The ``nova-serialproxy`` service is called with this token enriched URL # and establishes the connection to the proper instance. # # Related options: # # * The IP address must be identical to the address to which the # ``nova-serialproxy`` service is listening (see option ``serialproxy_host`` # in this section). # * The port must be the same as in the option ``serialproxy_port`` of this # section. # * If you choose to use a secured websocket connection, then start this option # with ``wss://`` instead of the unsecured ``ws://``. The options ``cert`` # and ``key`` in the ``[DEFAULT]`` section have to be set for that. # (uri value) #base_url = ws://127.0.0.1:6083/ # # The IP address to which proxy clients (like ``nova-serialproxy``) should # connect to get the serial console of an instance. # # This is typically the IP address of the host of a ``nova-compute`` service. # (string value) #proxyclient_address = 127.0.0.1 # # The IP address which is used by the ``nova-serialproxy`` service to listen # for incoming requests. # # The ``nova-serialproxy`` service listens on this IP address for incoming # connection requests to instances which expose serial console. # # Related options: # # * Ensure that this is the same IP address which is defined in the option # ``base_url`` of this section or use ``0.0.0.0`` to listen on all addresses. # (string value) #serialproxy_host = 0.0.0.0 # # The port number which is used by the ``nova-serialproxy`` service to listen # for incoming requests. # # The ``nova-serialproxy`` service listens on this port number for incoming # connection requests to instances which expose serial console. # # Related options: # # * Ensure that this is the same port number which is defined in the option # ``base_url`` of this section. # (port value) # Minimum value: 0 # Maximum value: 65535 #serialproxy_port = 6083 [service_user] # # Configuration options for service to service authentication using a service # token. These options allow sending a service token along with the user's token # when contacting external REST APIs. # # From nova.conf # # # When True, if sending a user token to a REST API, also send a service token. # # Nova often reuses the user token provided to the nova-api to talk to other # REST # APIs, such as Cinder, Glance and Neutron. It is possible that while the user # token was valid when the request was made to Nova, the token may expire before # it reaches the other service. To avoid any failures, and to make it clear it # is # Nova calling the service on the user's behalf, we include a service token # along # with the user token. Should the user's token have expired, a valid service # token ensures the REST API request will still be accepted by the keystone # middleware. # (boolean value) #send_service_user_token = false # PEM encoded Certificate Authority to use when verifying HTTPs connections. # (string value) #cafile = # PEM encoded client certificate cert file (string value) #certfile = # PEM encoded client certificate key file (string value) #keyfile = # Verify HTTPS connections. (boolean value) #insecure = false # Timeout value for http requests (integer value) #timeout = # Authentication type to load (string value) # Deprecated group/name - [service_user]/auth_plugin #auth_type = # Config Section from which to load plugin specific options (string value) #auth_section = # Authentication URL (string value) #auth_url = # Scope for system operations (string value) #system_scope = # Domain ID to scope to (string value) #domain_id = # Domain name to scope to (string value) #domain_name = # Project ID to scope to (string value) #project_id = # Project name to scope to (string value) #project_name = # Domain ID containing project (string value) #project_domain_id = # Domain name containing project (string value) #project_domain_name = # Trust ID (string value) #trust_id = # Optional domain ID to use with v3 and v2 parameters. It will be used for both # the user and project domain in v3 and ignored in v2 authentication. (string # value) #default_domain_id = # Optional domain name to use with v3 API and v2 parameters. It will be used for # both the user and project domain in v3 and ignored in v2 authentication. # (string value) #default_domain_name = # User ID (string value) #user_id = # Username (string value) # Deprecated group/name - [service_user]/user_name #username = # User's domain id (string value) #user_domain_id = # User's domain name (string value) #user_domain_name = # User's password (string value) #password = # Tenant ID (string value) #tenant_id = # Tenant Name (string value) #tenant_name = [spice] # # SPICE console feature allows you to connect to a guest virtual machine. # SPICE is a replacement for fairly limited VNC protocol. # # Following requirements must be met in order to use SPICE: # # * Virtualization driver must be libvirt # * spice.enabled set to True # * vnc.enabled set to False # * update html5proxy_base_url # * update server_proxyclient_address # # From nova.conf # # # Enable SPICE related features. # # Related options: # # * VNC must be explicitly disabled to get access to the SPICE console. Set the # enabled option to False in the [vnc] section to disable the VNC console. # (boolean value) #enabled = false # # Enable the SPICE guest agent support on the instances. # # The Spice agent works with the Spice protocol to offer a better guest console # experience. However, the Spice console can still be used without the Spice # Agent. With the Spice agent installed the following features are enabled: # # * Copy & Paste of text and images between the guest and client machine # * Automatic adjustment of resolution when the client screen changes - e.g. # if you make the Spice console full screen the guest resolution will adjust # to # match it rather than letterboxing. # * Better mouse integration - The mouse can be captured and released without # needing to click inside the console or press keys to release it. The # performance of mouse movement is also improved. # (boolean value) #agent_enabled = true # # Location of the SPICE HTML5 console proxy. # # End user would use this URL to connect to the `nova-spicehtml5proxy`` # service. This service will forward request to the console of an instance. # # In order to use SPICE console, the service ``nova-spicehtml5proxy`` should be # running. This service is typically launched on the controller node. # # Possible values: # # * Must be a valid URL of the form: ``http://host:port/spice_auto.html`` # where host is the node running ``nova-spicehtml5proxy`` and the port is # typically 6082. Consider not using default value as it is not well defined # for any real deployment. # # Related options: # # * This option depends on ``html5proxy_host`` and ``html5proxy_port`` options. # The access URL returned by the compute node must have the host # and port where the ``nova-spicehtml5proxy`` service is listening. # (uri value) #html5proxy_base_url = http://127.0.0.1:6082/spice_auto.html # # The address where the SPICE server running on the instances should listen. # # Typically, the ``nova-spicehtml5proxy`` proxy client runs on the controller # node and connects over the private network to this address on the compute # node(s). # # Possible values: # # * IP address to listen on. # (string value) #server_listen = 127.0.0.1 # # The address used by ``nova-spicehtml5proxy`` client to connect to instance # console. # # Typically, the ``nova-spicehtml5proxy`` proxy client runs on the # controller node and connects over the private network to this address on the # compute node(s). # # Possible values: # # * Any valid IP address on the compute node. # # Related options: # # * This option depends on the ``server_listen`` option. # The proxy client must be able to access the address specified in # ``server_listen`` using the value of this option. # (string value) #server_proxyclient_address = 127.0.0.1 # # A keyboard layout which is supported by the underlying hypervisor on this # node. # # Possible values: # * This is usually an 'IETF language tag' (default is 'en-us'). If you # use QEMU as hypervisor, you should find the list of supported keyboard # layouts at /usr/share/qemu/keymaps. # (string value) #keymap = en-us # # IP address or a hostname on which the ``nova-spicehtml5proxy`` service # listens for incoming requests. # # Related options: # # * This option depends on the ``html5proxy_base_url`` option. # The ``nova-spicehtml5proxy`` service must be listening on a host that is # accessible from the HTML5 client. # (unknown value) #html5proxy_host = 0.0.0.0 # # Port on which the ``nova-spicehtml5proxy`` service listens for incoming # requests. # # Related options: # # * This option depends on the ``html5proxy_base_url`` option. # The ``nova-spicehtml5proxy`` service must be listening on a port that is # accessible from the HTML5 client. # (port value) # Minimum value: 0 # Maximum value: 65535 #html5proxy_port = 6082 [upgrade_levels] # # upgrade_levels options are used to set version cap for RPC # messages sent between different nova services. # # By default all services send messages using the latest version # they know about. # # The compute upgrade level is an important part of rolling upgrades # where old and new nova-compute services run side by side. # # The other options can largely be ignored, and are only kept to # help with a possible future backport issue. # # From nova.conf # # # Compute RPC API version cap. # # By default, we always send messages using the most recent version # the client knows about. # # Where you have old and new compute services running, you should set # this to the lowest deployed version. This is to guarantee that all # services never send messages that one of the compute nodes can't # understand. Note that we only support upgrading from release N to # release N+1. # # Set this option to "auto" if you want to let the compute RPC module # automatically determine what version to use based on the service # versions in the deployment. # # Possible values: # # * By default send the latest version the client knows about # * 'auto': Automatically determines what version to use based on # the service versions in the deployment. # * A string representing a version number in the format 'N.N'; # for example, possible values might be '1.12' or '2.0'. # * An OpenStack release name, in lower case, such as 'mitaka' or # 'liberty'. # (string value) #compute = # Cells RPC API version cap (string value) #cells = # Intercell RPC API version cap (string value) #intercell = # Cert RPC API version cap (string value) #cert = # Scheduler RPC API version cap (string value) #scheduler = # Conductor RPC API version cap (string value) #conductor = # Console RPC API version cap (string value) #console = # Consoleauth RPC API version cap (string value) #consoleauth = # Network RPC API version cap (string value) #network = # Base API RPC API version cap (string value) #baseapi = [vault] # # From nova.conf # # root token for vault (string value) #root_token_id = # Use this endpoint to connect to Vault, for example: "http://127.0.0.1:8200" # (string value) #vault_url = http://127.0.0.1:8200 # Absolute path to ca cert file (string value) #ssl_ca_crt_file = # SSL Enabled/Disabled (boolean value) #use_ssl = false [vendordata_dynamic_auth] # # Options within this group control the authentication of the vendordata # subsystem of the metadata API server (and config drive) with external systems. # # From nova.conf # # PEM encoded Certificate Authority to use when verifying HTTPs connections. # (string value) #cafile = # PEM encoded client certificate cert file (string value) #certfile = # PEM encoded client certificate key file (string value) #keyfile = # Verify HTTPS connections. (boolean value) #insecure = false # Timeout value for http requests (integer value) #timeout = # Authentication type to load (string value) # Deprecated group/name - [vendordata_dynamic_auth]/auth_plugin #auth_type = # Config Section from which to load plugin specific options (string value) #auth_section = # Authentication URL (string value) #auth_url = # Scope for system operations (string value) #system_scope = # Domain ID to scope to (string value) #domain_id = # Domain name to scope to (string value) #domain_name = # Project ID to scope to (string value) #project_id = # Project name to scope to (string value) #project_name = # Domain ID containing project (string value) #project_domain_id = # Domain name containing project (string value) #project_domain_name = # Trust ID (string value) #trust_id = # Optional domain ID to use with v3 and v2 parameters. It will be used for both # the user and project domain in v3 and ignored in v2 authentication. (string # value) #default_domain_id = # Optional domain name to use with v3 API and v2 parameters. It will be used for # both the user and project domain in v3 and ignored in v2 authentication. # (string value) #default_domain_name = # User ID (string value) #user_id = # Username (string value) # Deprecated group/name - [vendordata_dynamic_auth]/user_name #username = # User's domain id (string value) #user_domain_id = # User's domain name (string value) #user_domain_name = # User's password (string value) #password = # Tenant ID (string value) #tenant_id = # Tenant Name (string value) #tenant_name = [vmware] # # Related options: # Following options must be set in order to launch VMware-based # virtual machines. # # * compute_driver: Must use vmwareapi.VMwareVCDriver. # * vmware.host_username # * vmware.host_password # * vmware.cluster_name # # From nova.conf # # # This option specifies the physical ethernet adapter name for VLAN # networking. # # Set the vlan_interface configuration option to match the ESX host # interface that handles VLAN-tagged VM traffic. # # Possible values: # # * Any valid string representing VLAN interface name # (string value) #vlan_interface = vmnic0 # # This option should be configured only when using the NSX-MH Neutron # plugin. This is the name of the integration bridge on the ESXi server # or host. This should not be set for any other Neutron plugin. Hence # the default value is not set. # # Possible values: # # * Any valid string representing the name of the integration bridge # (string value) #integration_bridge = # # Set this value if affected by an increased network latency causing # repeated characters when typing in a remote console. # (integer value) # Minimum value: 0 #console_delay_seconds = # # Identifies the remote system where the serial port traffic will # be sent. # # This option adds a virtual serial port which sends console output to # a configurable service URI. At the service URI address there will be # virtual serial port concentrator that will collect console logs. # If this is not set, no serial ports will be added to the created VMs. # # Possible values: # # * Any valid URI # (string value) #serial_port_service_uri = # # Identifies a proxy service that provides network access to the # serial_port_service_uri. # # Possible values: # # * Any valid URI (The scheme is 'telnet' or 'telnets'.) # # Related options: # This option is ignored if serial_port_service_uri is not specified. # * serial_port_service_uri # (uri value) #serial_port_proxy_uri = # # Specifies the directory where the Virtual Serial Port Concentrator is # storing console log files. It should match the 'serial_log_dir' config # value of VSPC. # (string value) #serial_log_dir = /opt/vmware/vspc # # Hostname or IP address for connection to VMware vCenter host. (unknown value) #host_ip = # Port for connection to VMware vCenter host. (port value) # Minimum value: 0 # Maximum value: 65535 #host_port = 443 # Username for connection to VMware vCenter host. (string value) #host_username = # Password for connection to VMware vCenter host. (string value) #host_password = # # Specifies the CA bundle file to be used in verifying the vCenter # server certificate. # (string value) #ca_file = # # If true, the vCenter server certificate is not verified. If false, # then the default CA truststore is used for verification. # # Related options: # * ca_file: This option is ignored if "ca_file" is set. # (boolean value) #insecure = false # Name of a VMware Cluster ComputeResource. (string value) #cluster_name = # # Regular expression pattern to match the name of datastore. # # The datastore_regex setting specifies the datastores to use with # Compute. For example, datastore_regex="nas.*" selects all the data # stores that have a name starting with "nas". # # NOTE: If no regex is given, it just picks the datastore with the # most freespace. # # Possible values: # # * Any matching regular expression to a datastore must be given # (string value) #datastore_regex = # # Time interval in seconds to poll remote tasks invoked on # VMware VC server. # (floating point value) #task_poll_interval = 0.5 # # Number of times VMware vCenter server API must be retried on connection # failures, e.g. socket error, etc. # (integer value) # Minimum value: 0 #api_retry_count = 10 # # This option specifies VNC starting port. # # Every VM created by ESX host has an option of enabling VNC client # for remote connection. Above option 'vnc_port' helps you to set # default starting port for the VNC client. # # Possible values: # # * Any valid port number within 5900 -(5900 + vnc_port_total) # # Related options: # Below options should be set to enable VNC client. # * vnc.enabled = True # * vnc_port_total # (port value) # Minimum value: 0 # Maximum value: 65535 #vnc_port = 5900 # # Total number of VNC ports. # (integer value) # Minimum value: 0 #vnc_port_total = 10000 # # This option enables/disables the use of linked clone. # # The ESX hypervisor requires a copy of the VMDK file in order to boot # up a virtual machine. The compute driver must download the VMDK via # HTTP from the OpenStack Image service to a datastore that is visible # to the hypervisor and cache it. Subsequent virtual machines that need # the VMDK use the cached version and don't have to copy the file again # from the OpenStack Image service. # # If set to false, even with a cached VMDK, there is still a copy # operation from the cache location to the hypervisor file directory # in the shared datastore. If set to true, the above copy operation # is avoided as it creates copy of the virtual machine that shares # virtual disks with its parent VM. # (boolean value) #use_linked_clone = true # # This option sets the http connection pool size # # The connection pool size is the maximum number of connections from nova to # vSphere. It should only be increased if there are warnings indicating that # the connection pool is full, otherwise, the default should suffice. # (integer value) # Minimum value: 10 #connection_pool_size = 10 # # This option enables or disables storage policy based placement # of instances. # # Related options: # # * pbm_default_policy # (boolean value) #pbm_enabled = false # # This option specifies the PBM service WSDL file location URL. # # Setting this will disable storage policy based placement # of instances. # # Possible values: # # * Any valid file path # e.g file:///opt/SDK/spbm/wsdl/pbmService.wsdl # (string value) #pbm_wsdl_location = # # This option specifies the default policy to be used. # # If pbm_enabled is set and there is no defined storage policy for the # specific request, then this policy will be used. # # Possible values: # # * Any valid storage policy such as VSAN default storage policy # # Related options: # # * pbm_enabled # (string value) #pbm_default_policy = # # This option specifies the limit on the maximum number of objects to # return in a single result. # # A positive value will cause the operation to suspend the retrieval # when the count of objects reaches the specified limit. The server may # still limit the count to something less than the configured value. # Any remaining objects may be retrieved with additional requests. # (integer value) # Minimum value: 0 #maximum_objects = 100 # # This option adds a prefix to the folder where cached images are stored # # This is not the full path - just a folder prefix. This should only be # used when a datastore cache is shared between compute nodes. # # Note: This should only be used when the compute nodes are running on same # host or they have a shared file system. # # Possible values: # # * Any string representing the cache prefix to the folder # (string value) #cache_prefix = [vnc] # # Virtual Network Computer (VNC) can be used to provide remote desktop # console access to instances for tenants and/or administrators. #pavlos --start enabled = true server_listen = 0.0.0.0 server_proxyclient_address = $my_ip novncproxy_base_url = http://controller:6080/vnc_auto.html #pavlos --end # # From nova.conf # # # Enable VNC related features. # # Guests will get created with graphical devices to support this. Clients # (for example Horizon) can then establish a VNC connection to the guest. # (boolean value) # Deprecated group/name - [DEFAULT]/vnc_enabled #enabled = true # # Keymap for VNC. # # The keyboard mapping (keymap) determines which keyboard layout a VNC # session should use by default. # # Possible values: # # * A keyboard layout which is supported by the underlying hypervisor on # this node. This is usually an 'IETF language tag' (for example # 'en-us'). If you use QEMU as hypervisor, you should find the list # of supported keyboard layouts at ``/usr/share/qemu/keymaps``. # (string value) # Deprecated group/name - [DEFAULT]/vnc_keymap #keymap = en-us # # The IP address or hostname on which an instance should listen to for # incoming VNC connection requests on this node. # (unknown value) # Deprecated group/name - [DEFAULT]/vncserver_listen # Deprecated group/name - [vnc]/vncserver_listen #server_listen = 127.0.0.1 # # Private, internal IP address or hostname of VNC console proxy. # # The VNC proxy is an OpenStack component that enables compute service # users to access their instances through VNC clients. # # This option sets the private address to which proxy clients, such as # ``nova-xvpvncproxy``, should connect to. # (unknown value) # Deprecated group/name - [DEFAULT]/vncserver_proxyclient_address # Deprecated group/name - [vnc]/vncserver_proxyclient_address #server_proxyclient_address = 127.0.0.1 # # Public address of noVNC VNC console proxy. # # The VNC proxy is an OpenStack component that enables compute service # users to access their instances through VNC clients. noVNC provides # VNC support through a websocket-based client. # # This option sets the public base URL to which client systems will # connect. noVNC clients can use this address to connect to the noVNC # instance and, by extension, the VNC sessions. # # Related options: # # * novncproxy_host # * novncproxy_port # (uri value) #novncproxy_base_url = http://127.0.0.1:6080/vnc_auto.html # # IP address or hostname that the XVP VNC console proxy should bind to. # # The VNC proxy is an OpenStack component that enables compute service # users to access their instances through VNC clients. Xen provides # the Xenserver VNC Proxy, or XVP, as an alternative to the # websocket-based noVNC proxy used by Libvirt. In contrast to noVNC, # XVP clients are Java-based. # # This option sets the private address to which the XVP VNC console proxy # service should bind to. # # Related options: # # * xvpvncproxy_port # * xvpvncproxy_base_url # (unknown value) #xvpvncproxy_host = 0.0.0.0 # # Port that the XVP VNC console proxy should bind to. # # The VNC proxy is an OpenStack component that enables compute service # users to access their instances through VNC clients. Xen provides # the Xenserver VNC Proxy, or XVP, as an alternative to the # websocket-based noVNC proxy used by Libvirt. In contrast to noVNC, # XVP clients are Java-based. # # This option sets the private port to which the XVP VNC console proxy # service should bind to. # # Related options: # # * xvpvncproxy_host # * xvpvncproxy_base_url # (port value) # Minimum value: 0 # Maximum value: 65535 #xvpvncproxy_port = 6081 # # Public URL address of XVP VNC console proxy. # # The VNC proxy is an OpenStack component that enables compute service # users to access their instances through VNC clients. Xen provides # the Xenserver VNC Proxy, or XVP, as an alternative to the # websocket-based noVNC proxy used by Libvirt. In contrast to noVNC, # XVP clients are Java-based. # # This option sets the public base URL to which client systems will # connect. XVP clients can use this address to connect to the XVP # instance and, by extension, the VNC sessions. # # Related options: # # * xvpvncproxy_host # * xvpvncproxy_port # (uri value) #xvpvncproxy_base_url = http://127.0.0.1:6081/console # # IP address that the noVNC console proxy should bind to. # # The VNC proxy is an OpenStack component that enables compute service # users to access their instances through VNC clients. noVNC provides # VNC support through a websocket-based client. # # This option sets the private address to which the noVNC console proxy # service should bind to. # # Related options: # # * novncproxy_port # * novncproxy_base_url # (string value) #novncproxy_host = 0.0.0.0 # # Port that the noVNC console proxy should bind to. # # The VNC proxy is an OpenStack component that enables compute service # users to access their instances through VNC clients. noVNC provides # VNC support through a websocket-based client. # # This option sets the private port to which the noVNC console proxy # service should bind to. # # Related options: # # * novncproxy_host # * novncproxy_base_url # (port value) # Minimum value: 0 # Maximum value: 65535 #novncproxy_port = 6080 # # The authentication schemes to use with the compute node. # # Control what RFB authentication schemes are permitted for connections between # the proxy and the compute host. If multiple schemes are enabled, the first # matching scheme will be used, thus the strongest schemes should be listed # first. # # Possible values: # # * ``none``: allow connection without authentication # * ``vencrypt``: use VeNCrypt authentication scheme # # Related options: # # * ``[vnc]vencrypt_client_key``, ``[vnc]vencrypt_client_cert``: must also be # set # (list value) #auth_schemes = none # The path to the client certificate PEM file (for x509) # # The fully qualified path to a PEM file containing the private key which the # VNC # proxy server presents to the compute node during VNC authentication. # # Related options: # # * ``vnc.auth_schemes``: must include ``vencrypt`` # * ``vnc.vencrypt_client_cert``: must also be set # (string value) #vencrypt_client_key = # The path to the client key file (for x509) # # The fully qualified path to a PEM file containing the x509 certificate which # the VNC proxy server presents to the compute node during VNC authentication. # # Realted options: # # * ``vnc.auth_schemes``: must include ``vencrypt`` # * ``vnc.vencrypt_client_key``: must also be set # (string value) #vencrypt_client_cert = # The path to the CA certificate PEM file # # The fully qualified path to a PEM file containing one or more x509 # certificates # for the certificate authorities used by the compute node VNC server. # # Related options: # # * ``vnc.auth_schemes``: must include ``vencrypt`` # (string value) #vencrypt_ca_certs = [workarounds] # # A collection of workarounds used to mitigate bugs or issues found in system # tools (e.g. Libvirt or QEMU) or Nova itself under certain conditions. These # should only be enabled in exceptional circumstances. All options are linked # against bug IDs, where more information on the issue can be found. # # From nova.conf # # # Use sudo instead of rootwrap. # # Allow fallback to sudo for performance reasons. # # For more information, refer to the bug report: # # https://bugs.launchpad.net/nova/+bug/1415106 # # Possible values: # # * True: Use sudo instead of rootwrap # * False: Use rootwrap as usual # # Interdependencies to other options: # # * Any options that affect 'rootwrap' will be ignored. # (boolean value) #disable_rootwrap = false # # Disable live snapshots when using the libvirt driver. # # Live snapshots allow the snapshot of the disk to happen without an # interruption to the guest, using coordination with a guest agent to # quiesce the filesystem. # # When using libvirt 1.2.2 live snapshots fail intermittently under load # (likely related to concurrent libvirt/qemu operations). This config # option provides a mechanism to disable live snapshot, in favor of cold # snapshot, while this is resolved. Cold snapshot causes an instance # outage while the guest is going through the snapshotting process. # # For more information, refer to the bug report: # # https://bugs.launchpad.net/nova/+bug/1334398 # # Possible values: # # * True: Live snapshot is disabled when using libvirt # * False: Live snapshots are always used when snapshotting (as long as # there is a new enough libvirt and the backend storage supports it) # (boolean value) #disable_libvirt_livesnapshot = false # # Enable handling of events emitted from compute drivers. # # Many compute drivers emit lifecycle events, which are events that occur when, # for example, an instance is starting or stopping. If the instance is going # through task state changes due to an API operation, like resize, the events # are ignored. # # This is an advanced feature which allows the hypervisor to signal to the # compute service that an unexpected state change has occurred in an instance # and that the instance can be shutdown automatically. Unfortunately, this can # race in some conditions, for example in reboot operations or when the compute # service or when host is rebooted (planned or due to an outage). If such races # are common, then it is advisable to disable this feature. # # Care should be taken when this feature is disabled and # 'sync_power_state_interval' is set to a negative value. In this case, any # instances that get out of sync between the hypervisor and the Nova database # will have to be synchronized manually. # # For more information, refer to the bug report: # # https://bugs.launchpad.net/bugs/1444630 # # Interdependencies to other options: # # * If ``sync_power_state_interval`` is negative and this feature is disabled, # then instances that get out of sync between the hypervisor and the Nova # database will have to be synchronized manually. # (boolean value) #handle_virt_lifecycle_events = true # # Disable the server group policy check upcall in compute. # # In order to detect races with server group affinity policy, the compute # service attempts to validate that the policy was not violated by the # scheduler. It does this by making an upcall to the API database to list # the instances in the server group for one that it is booting, which violates # our api/cell isolation goals. Eventually this will be solved by proper # affinity # guarantees in the scheduler and placement service, but until then, this late # check is needed to ensure proper affinity policy. # # Operators that desire api/cell isolation over this check should # enable this flag, which will avoid making that upcall from compute. # # Related options: # # * [filter_scheduler]/track_instance_changes also relies on upcalls from the # compute service to the scheduler service. # (boolean value) #disable_group_policy_check_upcall = false # # Ensure the instance directory is removed during clean up when using rbd. # # When enabled this workaround will ensure that the instance directory is always # removed during cleanup on hosts using ``[libvirt]/images_type=rbd``. This # avoids the following bugs with evacuation and revert resize clean up that lead # to the instance directory remaining on the host: # # https://bugs.launchpad.net/nova/+bug/1414895 # # https://bugs.launchpad.net/nova/+bug/1761062 # # Both of these bugs can then result in ``DestinationDiskExists`` errors being # raised if the instances ever attempt to return to the host. # # .. warning:: Operators will need to ensure that the instance directory itself, # specified by ``[DEFAULT]/instances_path``, is not shared between computes # before enabling this workaround otherwise the console.log, kernels, ramdisks # and any additional files being used by the running instance will be lost. # # Related options: # # * ``compute_driver`` (libvirt) # * ``[libvirt]/images_type`` (rbd) # * ``instances_path`` # (boolean value) #ensure_libvirt_rbd_instance_dir_cleanup = false # # Enable live migration of instances with NUMA topologies. # # Live migration of instances with NUMA topologies is disabled by default # when using the libvirt driver. This includes live migration of instances with # CPU pinning or hugepages. CPU pinning and huge page information for such # instances is not currently re-calculated, as noted in bug #1289064. This # means that if instances were already present on the destination host, the # migrated instance could be placed on the same dedicated cores as these # instances or use hugepages allocated for another instance. Alternately, if the # host platforms were not homogeneous, the instance could be assigned to # non-existent cores or be inadvertently split across host NUMA nodes. # # Despite these known issues, there may be cases where live migration is # necessary. By enabling this option, operators that are aware of the issues and # are willing to manually work around them can enable live migration support for # these instances. # # Related options: # # * ``compute_driver``: Only the libvirt driver is affected. # (boolean value) #enable_numa_live_migration = false [wsgi] # # Options under this group are used to configure WSGI (Web Server Gateway # Interface). WSGI is used to serve API requests. # # From nova.conf # # # This option represents a file name for the paste.deploy config for nova-api. # # Possible values: # # * A string representing file name for the paste.deploy config. # (string value) #api_paste_config = api-paste.ini # DEPRECATED: # It represents a python format string that is used as the template to generate # log lines. The following values can be formatted into it: client_ip, # date_time, request_line, status_code, body_length, wall_seconds. # # This option is used for building custom request loglines when running # nova-api under eventlet. If used under uwsgi or apache, this option # has no effect. # # Possible values: # # * '%(client_ip)s "%(request_line)s" status: %(status_code)s' # 'len: %(body_length)s time: %(wall_seconds).7f' (default) # * Any formatted string formed by specific values. # (string value) # This option is deprecated for removal since 16.0.0. # Its value may be silently ignored in the future. # Reason: # This option only works when running nova-api under eventlet, and # encodes very eventlet specific pieces of information. Starting in Pike # the preferred model for running nova-api is under uwsgi or apache # mod_wsgi. #wsgi_log_format = %(client_ip)s "%(request_line)s" status: %(status_code)s len: %(body_length)s time: %(wall_seconds).7f # # This option specifies the HTTP header used to determine the protocol scheme # for the original request, even if it was removed by a SSL terminating proxy. # # Possible values: # # * None (default) - the request scheme is not influenced by any HTTP headers # * Valid HTTP header, like HTTP_X_FORWARDED_PROTO # # WARNING: Do not set this unless you know what you are doing. # # Make sure ALL of the following are true before setting this (assuming the # values from the example above): # * Your API is behind a proxy. # * Your proxy strips the X-Forwarded-Proto header from all incoming requests. # In other words, if end users include that header in their requests, the # proxy # will discard it. # * Your proxy sets the X-Forwarded-Proto header and sends it to API, but only # for requests that originally come in via HTTPS. # # If any of those are not true, you should keep this setting set to None. # # (string value) #secure_proxy_ssl_header = # # This option allows setting path to the CA certificate file that should be used # to verify connecting clients. # # Possible values: # # * String representing path to the CA certificate file. # # Related options: # # * enabled_ssl_apis # (string value) #ssl_ca_file = # # This option allows setting path to the SSL certificate of API server. # # Possible values: # # * String representing path to the SSL certificate. # # Related options: # # * enabled_ssl_apis # (string value) #ssl_cert_file = # # This option specifies the path to the file where SSL private key of API # server is stored when SSL is in effect. # # Possible values: # # * String representing path to the SSL private key. # # Related options: # # * enabled_ssl_apis # (string value) #ssl_key_file = # # This option sets the value of TCP_KEEPIDLE in seconds for each server socket. # It specifies the duration of time to keep connection active. TCP generates a # KEEPALIVE transmission for an application that requests to keep connection # active. Not supported on OS X. # # Related options: # # * keep_alive # (integer value) # Minimum value: 0 #tcp_keepidle = 600 # # This option specifies the size of the pool of greenthreads used by wsgi. # It is possible to limit the number of concurrent connections using this # option. # (integer value) # Minimum value: 0 # Deprecated group/name - [DEFAULT]/wsgi_default_pool_size #default_pool_size = 1000 # # This option specifies the maximum line size of message headers to be accepted. # max_header_line may need to be increased when using large tokens (typically # those generated by the Keystone v3 API with big service catalogs). # # Since TCP is a stream based protocol, in order to reuse a connection, the HTTP # has to have a way to indicate the end of the previous response and beginning # of the next. Hence, in a keep_alive case, all messages must have a # self-defined message length. # (integer value) # Minimum value: 0 #max_header_line = 16384 # # This option allows using the same TCP connection to send and receive multiple # HTTP requests/responses, as opposed to opening a new one for every single # request/response pair. HTTP keep-alive indicates HTTP connection reuse. # # Possible values: # # * True : reuse HTTP connection. # * False : closes the client socket connection explicitly. # # Related options: # # * tcp_keepidle # (boolean value) # Deprecated group/name - [DEFAULT]/wsgi_keep_alive #keep_alive = true # # This option specifies the timeout for client connections' socket operations. # If an incoming connection is idle for this number of seconds it will be # closed. It indicates timeout on individual read/writes on the socket # connection. To wait forever set to 0. # (integer value) # Minimum value: 0 #client_socket_timeout = 900 [xenserver] # # XenServer options are used when the compute_driver is set to use # XenServer (compute_driver=xenapi.XenAPIDriver). # # Must specify connection_url, connection_password and ovs_integration_bridge to # use compute_driver=xenapi.XenAPIDriver. # # From nova.conf # # # Number of seconds to wait for agent's reply to a request. # # Nova configures/performs certain administrative actions on a server with the # help of an agent that's installed on the server. The communication between # Nova and the agent is achieved via sharing messages, called records, over # xenstore, a shared storage across all the domains on a Xenserver host. # Operations performed by the agent on behalf of nova are: 'version',' # key_init', # 'password','resetnetwork','inject_file', and 'agentupdate'. # # To perform one of the above operations, the xapi 'agent' plugin writes the # command and its associated parameters to a certain location known to the # domain # and awaits response. On being notified of the message, the agent performs # appropriate actions on the server and writes the result back to xenstore. This # result is then read by the xapi 'agent' plugin to determine the # success/failure # of the operation. # # This config option determines how long the xapi 'agent' plugin shall wait to # read the response off of xenstore for a given request/command. If the agent on # the instance fails to write the result in this time period, the operation is # considered to have timed out. # # Related options: # # * ``agent_version_timeout`` # * ``agent_resetnetwork_timeout`` # # (integer value) # Minimum value: 0 #agent_timeout = 30 # # Number of seconds to wait for agent't reply to version request. # # This indicates the amount of time xapi 'agent' plugin waits for the agent to # respond to the 'version' request specifically. The generic timeout for agent # communication ``agent_timeout`` is ignored in this case. # # During the build process the 'version' request is used to determine if the # agent is available/operational to perform other requests such as # 'resetnetwork', 'password', 'key_init' and 'inject_file'. If the 'version' # call # fails, the other configuration is skipped. So, this configuration option can # also be interpreted as time in which agent is expected to be fully # operational. # (integer value) # Minimum value: 0 #agent_version_timeout = 300 # # Number of seconds to wait for agent's reply to resetnetwork # request. # # This indicates the amount of time xapi 'agent' plugin waits for the agent to # respond to the 'resetnetwork' request specifically. The generic timeout for # agent communication ``agent_timeout`` is ignored in this case. # (integer value) # Minimum value: 0 #agent_resetnetwork_timeout = 60 # # Path to locate guest agent on the server. # # Specifies the path in which the XenAPI guest agent should be located. If the # agent is present, network configuration is not injected into the image. # # Related options: # # For this option to have an effect: # * ``flat_injected`` should be set to ``True`` # * ``compute_driver`` should be set to ``xenapi.XenAPIDriver`` # # (string value) #agent_path = usr/sbin/xe-update-networking # # Disables the use of XenAPI agent. # # This configuration option suggests whether the use of agent should be enabled # or not regardless of what image properties are present. Image properties have # an effect only when this is set to ``True``. Read description of config option # ``use_agent_default`` for more information. # # Related options: # # * ``use_agent_default`` # # (boolean value) #disable_agent = false # # Whether or not to use the agent by default when its usage is enabled but not # indicated by the image. # # The use of XenAPI agent can be disabled altogether using the configuration # option ``disable_agent``. However, if it is not disabled, the use of an agent # can still be controlled by the image in use through one of its properties, # ``xenapi_use_agent``. If this property is either not present or specified # incorrectly on the image, the use of agent is determined by this configuration # option. # # Note that if this configuration is set to ``True`` when the agent is not # present, the boot times will increase significantly. # # Related options: # # * ``disable_agent`` # # (boolean value) #use_agent_default = false # Timeout in seconds for XenAPI login. (integer value) # Minimum value: 0 #login_timeout = 10 # # Maximum number of concurrent XenAPI connections. # # In nova, multiple XenAPI requests can happen at a time. # Configuring this option will parallelize access to the XenAPI # session, which allows you to make concurrent XenAPI connections. # (integer value) # Minimum value: 1 #connection_concurrent = 5 # # Cache glance images locally. # # The value for this option must be chosen from the choices listed # here. Configuring a value other than these will default to 'all'. # # Note: There is nothing that deletes these images. # # Possible values: # # * `all`: will cache all images. # * `some`: will only cache images that have the # image_property `cache_in_nova=True`. # * `none`: turns off caching entirely. # (string value) # Possible values: # all - # some - # none - #cache_images = all # # Compression level for images. # # By setting this option we can configure the gzip compression level. # This option sets GZIP environment variable before spawning tar -cz # to force the compression level. It defaults to none, which means the # GZIP environment variable is not set and the default (usually -6) # is used. # # Possible values: # # * Range is 1-9, e.g., 9 for gzip -9, 9 being most # compressed but most CPU intensive on dom0. # * Any values out of this range will default to None. # (integer value) # Minimum value: 1 # Maximum value: 9 #image_compression_level = # Default OS type used when uploading an image to glance (string value) #default_os_type = linux # Time in secs to wait for a block device to be created (integer value) # Minimum value: 1 #block_device_creation_timeout = 10 # # Maximum size in bytes of kernel or ramdisk images. # # Specifying the maximum size of kernel or ramdisk will avoid copying # large files to dom0 and fill up /boot/guest. # (integer value) #max_kernel_ramdisk_size = 16777216 # # Filter for finding the SR to be used to install guest instances on. # # Possible values: # # * To use the Local Storage in default XenServer/XCP installations # set this flag to other-config:i18n-key=local-storage. # * To select an SR with a different matching criteria, you could # set it to other-config:my_favorite_sr=true. # * To fall back on the Default SR, as displayed by XenCenter, # set this flag to: default-sr:true. # (string value) #sr_matching_filter = default-sr:true # # Whether to use sparse_copy for copying data on a resize down. # (False will use standard dd). This speeds up resizes down # considerably since large runs of zeros won't have to be rsynced. # (boolean value) #sparse_copy = true # # Maximum number of retries to unplug VBD. # If set to 0, should try once, no retries. # (integer value) # Minimum value: 0 #num_vbd_unplug_retries = 10 # # Name of network to use for booting iPXE ISOs. # # An iPXE ISO is a specially crafted ISO which supports iPXE booting. # This feature gives a means to roll your own image. # # By default this option is not set. Enable this option to # boot an iPXE ISO. # # Related Options: # # * `ipxe_boot_menu_url` # * `ipxe_mkisofs_cmd` # (string value) #ipxe_network_name = # # URL to the iPXE boot menu. # # An iPXE ISO is a specially crafted ISO which supports iPXE booting. # This feature gives a means to roll your own image. # # By default this option is not set. Enable this option to # boot an iPXE ISO. # # Related Options: # # * `ipxe_network_name` # * `ipxe_mkisofs_cmd` # (string value) #ipxe_boot_menu_url = # # Name and optionally path of the tool used for ISO image creation. # # An iPXE ISO is a specially crafted ISO which supports iPXE booting. # This feature gives a means to roll your own image. # # Note: By default `mkisofs` is not present in the Dom0, so the # package can either be manually added to Dom0 or include the # `mkisofs` binary in the image itself. # # Related Options: # # * `ipxe_network_name` # * `ipxe_boot_menu_url` # (string value) #ipxe_mkisofs_cmd = mkisofs # # URL for connection to XenServer/Xen Cloud Platform. A special value # of unix://local can be used to connect to the local unix socket. # # Possible values: # # * Any string that represents a URL. The connection_url is # generally the management network IP address of the XenServer. # * This option must be set if you chose the XenServer driver. # (string value) #connection_url = # Username for connection to XenServer/Xen Cloud Platform (string value) #connection_username = root # Password for connection to XenServer/Xen Cloud Platform (string value) #connection_password = # # The interval used for polling of coalescing vhds. # # This is the interval after which the task of coalesce VHD is # performed, until it reaches the max attempts that is set by # vhd_coalesce_max_attempts. # # Related options: # # * `vhd_coalesce_max_attempts` # (floating point value) # Minimum value: 0 #vhd_coalesce_poll_interval = 5.0 # # Ensure compute service is running on host XenAPI connects to. # This option must be set to false if the 'independent_compute' # option is set to true. # # Possible values: # # * Setting this option to true will make sure that compute service # is running on the same host that is specified by connection_url. # * Setting this option to false, doesn't perform the check. # # Related options: # # * `independent_compute` # (boolean value) #check_host = true # # Max number of times to poll for VHD to coalesce. # # This option determines the maximum number of attempts that can be # made for coalescing the VHD before giving up. # # Related opitons: # # * `vhd_coalesce_poll_interval` # (integer value) # Minimum value: 0 #vhd_coalesce_max_attempts = 20 # Base path to the storage repository on the XenServer host. (string value) #sr_base_path = /var/run/sr-mount # # The iSCSI Target Host. # # This option represents the hostname or ip of the iSCSI Target. # If the target host is not present in the connection information from # the volume provider then the value from this option is taken. # # Possible values: # # * Any string that represents hostname/ip of Target. # (unknown value) #target_host = # # The iSCSI Target Port. # # This option represents the port of the iSCSI Target. If the # target port is not present in the connection information from the # volume provider then the value from this option is taken. # (port value) # Minimum value: 0 # Maximum value: 65535 #target_port = 3260 # # Used to prevent attempts to attach VBDs locally, so Nova can # be run in a VM on a different host. # # Related options: # # * ``CONF.flat_injected`` (Must be False) # * ``CONF.xenserver.check_host`` (Must be False) # * ``CONF.default_ephemeral_format`` (Must be unset or 'ext3') # * Joining host aggregates (will error if attempted) # * Swap disks for Windows VMs (will error if attempted) # * Nova-based auto_configure_disk (will error if attempted) # (boolean value) #independent_compute = false # # Wait time for instances to go to running state. # # Provide an integer value representing time in seconds to set the # wait time for an instance to go to running state. # # When a request to create an instance is received by nova-api and # communicated to nova-compute, the creation of the instance occurs # through interaction with Xen via XenAPI in the compute node. Once # the node on which the instance(s) are to be launched is decided by # nova-schedule and the launch is triggered, a certain amount of wait # time is involved until the instance(s) can become available and # 'running'. This wait time is defined by running_timeout. If the # instances do not go to running state within this specified wait # time, the launch expires and the instance(s) are set to 'error' # state. # (integer value) # Minimum value: 0 #running_timeout = 60 # DEPRECATED: # The XenAPI VIF driver using XenServer Network APIs. # # Provide a string value representing the VIF XenAPI vif driver to use for # plugging virtual network interfaces. # # Xen configuration uses bridging within the backend domain to allow # all VMs to appear on the network as individual hosts. Bridge # interfaces are used to create a XenServer VLAN network in which # the VIFs for the VM instances are plugged. If no VIF bridge driver # is plugged, the bridge is not made available. This configuration # option takes in a value for the VIF driver. # # Possible values: # # * nova.virt.xenapi.vif.XenAPIOpenVswitchDriver (default) # * nova.virt.xenapi.vif.XenAPIBridgeDriver (deprecated) # # Related options: # # * ``vlan_interface`` # * ``ovs_integration_bridge`` # (string value) # This option is deprecated for removal since 15.0.0. # Its value may be silently ignored in the future. # Reason: # There are only two in-tree vif drivers for XenServer. XenAPIBridgeDriver is # for # nova-network which is deprecated and XenAPIOpenVswitchDriver is for Neutron # which is the default configuration for Nova since the 15.0.0 Ocata release. In # the future the "use_neutron" configuration option will be used to determine # which vif driver to use. #vif_driver = nova.virt.xenapi.vif.XenAPIOpenVswitchDriver # # Dom0 plugin driver used to handle image uploads. # # Provide a string value representing a plugin driver required to # handle the image uploading to GlanceStore. # # Images, and snapshots from XenServer need to be uploaded to the data # store for use. image_upload_handler takes in a value for the Dom0 # plugin driver. This driver is then called to uplaod images to the # GlanceStore. # (string value) #image_upload_handler = nova.virt.xenapi.image.glance.GlanceStore # # Number of seconds to wait for SR to settle if the VDI # does not exist when first introduced. # # Some SRs, particularly iSCSI connections are slow to see the VDIs # right after they got introduced. Setting this option to a # time interval will make the SR to wait for that time period # before raising VDI not found exception. # (integer value) # Minimum value: 0 #introduce_vdi_retry_wait = 20 # # The name of the integration Bridge that is used with xenapi # when connecting with Open vSwitch. # # Note: The value of this config option is dependent on the # environment, therefore this configuration value must be set # accordingly if you are using XenAPI. # # Possible values: # # * Any string that represents a bridge name. # (string value) #ovs_integration_bridge = # # When adding new host to a pool, this will append a --force flag to the # command, forcing hosts to join a pool, even if they have different CPUs. # # Since XenServer version 5.6 it is possible to create a pool of hosts that have # different CPU capabilities. To accommodate CPU differences, XenServer limited # features it uses to determine CPU compatibility to only the ones that are # exposed by CPU and support for CPU masking was added. # Despite this effort to level differences between CPUs, it is still possible # that adding new host will fail, thus option to force join was introduced. # (boolean value) #use_join_force = true # # Publicly visible name for this console host. # # Possible values: # # * Current hostname (default) or any string representing hostname. # (string value) #console_public_hostname = [xvp] # # Configuration options for XVP. # # xvp (Xen VNC Proxy) is a proxy server providing password-protected VNC-based # access to the consoles of virtual machines hosted on Citrix XenServer. # # From nova.conf # # XVP conf template (string value) #console_xvp_conf_template = $pybasedir/nova/console/xvp.conf.template # Generated XVP conf file (string value) #console_xvp_conf = /etc/xvp.conf # XVP master process pid file (string value) #console_xvp_pid = /var/run/xvp.pid # XVP log file (string value) #console_xvp_log = /var/log/xvp.log # Port for XVP to multiplex VNC connections on (port value) # Minimum value: 0 # Maximum value: 65535 #console_xvp_multiplex_port = 5900 From radoslaw.piliszek at gmail.com Wed Nov 11 17:37:15 2020 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Wed, 11 Nov 2020 18:37:15 +0100 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: Message-ID: Thank you for the heads up. I write to confirm that Kolla has, for some time, not provided database credentials to nova-compute. -yoctozepto On Wed, Nov 11, 2020 at 5:36 PM Balázs Gibizer wrote: > > Dear packagers and deployment engine developers, > > Since Icehouse nova-compute service does not need any database > configuration as it uses the message bus to access data in the database > via the conductor service. Also, the nova configuration guide states > that the nova-compute service should not have the > [api_database]connection config set. Having any DB credentials > configured for the nova-compute is a security risk as well since that > service runs close to the hypervisor. Since Rocky[1] nova-compute > service fails if you configure API DB credentials and set upgrade_level > config to 'auto'. > > Now we are proposing a patch[2] that makes nova-compute fail at startup > if the [database]connection or the [api_database]connection is > configured. We know that this breaks at least the rpm packaging, debian > packaging, and puppet-nova. The problem there is that in an all-in-on > deployment scenario the nova.conf file generated by these tools is > shared between all the nova services and therefore nova-compute sees DB > credentials. As a counter-example, devstack generates a separate > nova-cpu.conf and passes that to the nova-compute service even in an > all-in-on setup. > > The nova team would like to merge [2] during Wallaby but we are OK to > delay the patch until Wallaby Milestone 2 so that the packagers and > deployment tools can catch up. Please let us know if you are impacted > and provide a way to track when you are ready with the modification > that allows [2] to be merged. > > There was a long discussion on #openstack-nova today[3] around this > topic. So you can find more detailed reasoning there[3]. > > Cheers, > gibi > > [1] > https://github.com/openstack/nova/blob/dc93e3b510f53d5b2198c8edd22528f0c899617e/nova/compute/rpcapi.py#L441-L457 > [2] https://review.opendev.org/#/c/762176 > [3] > http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2020-11-11.log.html#t2020-11-11T10:51:23 > -- > http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2020-11-11.log.html#t2020-11-11T14:40:51 > > > From smooney at redhat.com Wed Nov 11 17:47:49 2020 From: smooney at redhat.com (Sean Mooney) Date: Wed, 11 Nov 2020 17:47:49 +0000 Subject: Question about the instance snapshot In-Reply-To: <20201111154117.Horde.rS6VTlLeua6yUDh3vuci3HY@webmail.nde.ag> References: <20201111154117.Horde.rS6VTlLeua6yUDh3vuci3HY@webmail.nde.ag> Message-ID: <338088f61d60846718c3df3f117dd9adfdb28d32.camel@redhat.com> On Wed, 2020-11-11 at 15:41 +0000, Eugen Block wrote: > Hi, > > taking an instance snapshot only applies to the root disk, other  > attached disks are not included. yes this is by design. snapshot have only ever applied to the root disks volume snap shots can be done via the cinder api in a much more efficent way. > I don't have an explanation but I  > think it would be quite difficult to merge all contents from different  > disks into one image. well not just diffuclt it would be very in efficnt to use one image and unexpected to have an image per volume. its nut not in the scope of the nova snapshot api to do anything other then the root disk. volume snapshot realy should jsut be done on the backing store without transfering any data to glance and just using glance to store teh metadata. if we were to have qemu snapshot the volume it would have to potentialy copy a lot of data or invoke the existign volume snapshot apis and we have said in the past that nova should not proxy calls to other service that can be orchestrated externally. > If this is about backup and not creating new  > base images and your instances are volume-based you could create  > cinder snapshots of those volumes, for example by creating  > consistency-groups to have all volumes in a consistent state. > > If this is more about creating new base images rather than backups and  > you have an instance with its filesystem distributed across multiple  > volumes it would probably be better to either move everything to a  > single volume (easy when you're using LVM) or resize that instance  > with a larger disk size. There are several ways, it depends on your  > actual requirement. > > Regards, > Eugen > > > > Zitat von Henry lol : > > > Hello, everyone > > > > I'm wondering whether the snapshot from the instance saves all disks > > attached to the instance or only the main(=first) disk, because I can't > > find any clear description for it. yes it is only for the root disk. > > > > If the latter is true, should I detach all disks except for the main from > > the instance before taking a snapshot, and why doesn't it support all > > attached disks? > > > > Thanks > > Sincerely, > > > > From zigo at debian.org Wed Nov 11 17:52:34 2020 From: zigo at debian.org (Thomas Goirand) Date: Wed, 11 Nov 2020 18:52:34 +0100 Subject: [all] Fixtures & monkey patching issue with Python 3.9 Message-ID: <674bfdfb-495a-19e0-a306-b96aece85b14@debian.org> Hi, Please see these: https://bugs.debian.org/973239 https://github.com/testing-cabal/fixtures/issues/44 Is this affecting OpenStack? Could I just ignore these tests? Or is there an easy solution? Cheers, Thomas Goirand (zigo) From allison at openstack.org Wed Nov 11 20:06:52 2020 From: allison at openstack.org (Allison Price) Date: Wed, 11 Nov 2020 14:06:52 -0600 Subject: Victoria Release Community Meeting In-Reply-To: <20201111144618.ndckzezqgbb2xble@yuggoth.org> References: <1605050603.25113268@apps.rackspace.com> <4c09adb4-0f97-f256-9827-01781643a9c3@debian.org> <10079933.t8I2mb3pXR@p1> <20201111144618.ndckzezqgbb2xble@yuggoth.org> Message-ID: We can definitely consider using Jitsi for the next OIF community meeting. One significant feature that Zoom has is our ability to record the community meeting so that the rest of the community can watch on their own time, accommodating for different time zones. For those who do not wish to participate via Zoom tomorrow, the recording will be posted on YouTube and all of the PTLs share in their presentation how to connect with them via email or IRC. > On Nov 11, 2020, at 8:46 AM, Jeremy Stanley wrote: > > On 2020-11-11 13:24:25 +0100 (+0100), Slawek Kaplonski wrote: > [...] >> Actually foundation has Jitsii server also - see >> https://meetpad.opendev.org/ In Neutron team we were using it >> almost without problems during last PTG. > > It's not really "the foundation" though, it's run by the OpenDev > Collaboratory sysadmins and community. > >> But problem which we had with it was that it didn't work for >> people from China AFAIK so we had to switch to Zoom finally. > [...] > > This is unsubstantiated. We suspect people worldwide experience > problems with getting WebRTC traffic through corporate firewalls, > but on the whole people who live in mainland China have been > conditioned to assume anything which doesn't work is being blocked > by the government. We're working with some folks in China to attempt > to prove or disprove it, but coordinating between timezones has > slowed progress on that. We hope to have a better understanding of > the local access problems for China, if any, soon. > -- > Jeremy Stanley -------------- next part -------------- An HTML attachment was scrubbed... URL: From zigo at debian.org Wed Nov 11 20:08:47 2020 From: zigo at debian.org (Thomas Goirand) Date: Wed, 11 Nov 2020 21:08:47 +0100 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: Message-ID: On 11/11/20 5:35 PM, Balázs Gibizer wrote: > Dear packagers and deployment engine developers, > > Since Icehouse nova-compute service does not need any database > configuration as it uses the message bus to access data in the database > via the conductor service. Also, the nova configuration guide states > that the nova-compute service should not have the > [api_database]connection config set. Having any DB credentials > configured for the nova-compute is a security risk as well since that > service runs close to the hypervisor. Since Rocky[1] nova-compute > service fails if you configure API DB credentials and set upgrade_level > config to 'auto'. > > Now we are proposing a patch[2] that makes nova-compute fail at startup > if the [database]connection or the [api_database]connection is > configured. We know that this breaks at least the rpm packaging, debian > packaging, and puppet-nova. The problem there is that in an all-in-on > deployment scenario the nova.conf file generated by these tools is > shared between all the nova services and therefore nova-compute sees DB > credentials. As a counter-example, devstack generates a separate > nova-cpu.conf and passes that to the nova-compute service even in an > all-in-on setup. > > The nova team would like to merge [2] during Wallaby but we are OK to > delay the patch until Wallaby Milestone 2 so that the packagers and > deployment tools can catch up. Please let us know if you are impacted > and provide a way to track when you are ready with the modification that > allows [2] to be merged. > > There was a long discussion on #openstack-nova today[3] around this > topic. So you can find more detailed reasoning there[3]. > > Cheers, > gibi IMO, that's ok if, and only if, we all agree on how to implement it. Best would be if we (all downstream distro + config management) agree on how to implement this. How about, we all implement a /etc/nova/nova-db.conf, and get all services that need db access to use it (ie: starting them with --config-file=/etc/nova/nova-db.conf)? If I understand well, these services would need access to db: - conductor - scheduler - novncproxy - serialproxy - spicehtml5proxy - api - api-metadata Is this list correct? Or is there some services that also don't need it? Cheers, Thomas Goirand (zigo) From zigo at debian.org Wed Nov 11 20:58:12 2020 From: zigo at debian.org (Thomas Goirand) Date: Wed, 11 Nov 2020 21:58:12 +0100 Subject: Victoria Release Community Meeting In-Reply-To: References: <1605050603.25113268@apps.rackspace.com> <4c09adb4-0f97-f256-9827-01781643a9c3@debian.org> <10079933.t8I2mb3pXR@p1> <20201111144618.ndckzezqgbb2xble@yuggoth.org> Message-ID: On 11/11/20 9:06 PM, Allison Price wrote: > We can definitely consider using Jitsi for the next OIF community > meeting. One significant feature that Zoom has is our ability to record > the community meeting so that the rest of the community can watch on > their own time, accommodating for different time zones. For those who do > not wish to participate via Zoom tomorrow, the recording will be posted > on YouTube and all of the PTLs share in their presentation how to > connect with them via email or IRC. This can be done with Jitsi too (but not Jitsi alone). Again, if you don't know how, I can get you in touch with the Debconf video team. Cheers, Thomas Goirand (zigo) From smooney at redhat.com Wed Nov 11 21:06:43 2020 From: smooney at redhat.com (Sean Mooney) Date: Wed, 11 Nov 2020 21:06:43 +0000 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: Message-ID: On Wed, 2020-11-11 at 21:08 +0100, Thomas Goirand wrote: > On 11/11/20 5:35 PM, Balázs Gibizer wrote: > > Dear packagers and deployment engine developers, > > > > Since Icehouse nova-compute service does not need any database > > configuration as it uses the message bus to access data in the database > > via the conductor service. Also, the nova configuration guide states > > that the nova-compute service should not have the > > [api_database]connection config set. Having any DB credentials > > configured for the nova-compute is a security risk as well since that > > service runs close to the hypervisor. Since Rocky[1] nova-compute > > service fails if you configure API DB credentials and set upgrade_level > > config to 'auto'. > > > > Now we are proposing a patch[2] that makes nova-compute fail at startup > > if the [database]connection or the [api_database]connection is > > configured. We know that this breaks at least the rpm packaging, debian > > packaging, and puppet-nova. The problem there is that in an all-in-on > > deployment scenario the nova.conf file generated by these tools is > > shared between all the nova services and therefore nova-compute sees DB > > credentials. As a counter-example, devstack generates a separate > > nova-cpu.conf and passes that to the nova-compute service even in an > > all-in-on setup. > > > > The nova team would like to merge [2] during Wallaby but we are OK to > > delay the patch until Wallaby Milestone 2 so that the packagers and > > deployment tools can catch up. Please let us know if you are impacted > > and provide a way to track when you are ready with the modification that > > allows [2] to be merged. > > > > There was a long discussion on #openstack-nova today[3] around this > > topic. So you can find more detailed reasoning there[3]. > > > > Cheers, > > gibi > > IMO, that's ok if, and only if, we all agree on how to implement it. well not to be too blunt but im not sure we resonably can chose not to implement this. i has been raised by customer that have don a security audit in the past as a hardening issue that the db cred which are unused are present on the compute nodes. all agreeing to do it the same way woudl be a good thing but at the end of the day we should do this this cycle. we also shoudl come up with some upstream recomendation in the install docs on the best partice for this hopefully we can get agreement but if a specific config managment tool chosses to go a different way i dont think they should be force to chagne. for example kolla already dose the right thing and has for several releases. i dont think they shoudl need to change there approch. the have a singel nova.conf per container but a different one for each container https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/nova-cell/templates/nova.conf.j2#L136-L151 the nova.conf for the compute contaienr dose not contian the db info which is the correct approch. openstack ansible also do the same thing https://github.com/openstack/openstack-ansible-os_nova/blob/master/templates/nova.conf.j2#L183-L199 ooo will do the same thing once https://review.opendev.org/#/c/718552/ is done more or less. so form a config managment point of view the pattern is to generate a configile with only the info tha tis needed. form a packager point of view hte only way to mimic that is to use multiple files with descreeet chunks or to not install any config by default nad require operators to copy thet samples. the install guides dont expclitly call this out https://docs.openstack.org/nova/latest/install/controller-install-ubuntu.html#install-and-configure-components https://docs.openstack.org/nova/latest/install/compute-install-ubuntu.html#install-and-configure-components but the compute node one does not tell you to add the db config either. i do thikn we shoudl update the comptue node install docs to use a different file however instad of nova.conf. > Best would be if we (all downstream distro + config management) agree on > how to implement this. > > How about, we all implement a /etc/nova/nova-db.conf, and get all > services that need db access to use it (ie: starting them with > --config-file=/etc/nova/nova-db.conf)? we might want two db files so nova-cell-db and nova-api-db really > > If I understand well, these services would need access to db: > - conductor the super conductor need the cell db and the api db form talking to dan the instance affinity/antiaffintiy late check would reuire the cell db to unfortually need api db access too. > - scheduler the scudler need db acess although im not sure if it needs both. > - novncproxy > - serialproxy > - spicehtml5proxy so im not sure if these 3 do. they might for some kind fo token storage although i did not think they really should need db acess, maybe to get the instance host, it would be nice if these could be restrcted to just use the api db but they might need both. there is a propsal too support passwords with consoles. https://review.opendev.org/#/c/759828/ i have not check but i assume that will require tehm to have db access if they do not already. although i think the password enforcement might be via the hypervisor e.g. libvirt so they may not need db acess for that. we should determin that. > - api > - api-metadata the api and metadata api both need db acess yes. i think we need both the api db and cell db acess in both cases. > > Is this list correct? Or is there some services that also don't need it? the only other nova service is the compute agent and it does not need db acess. im not sure if there is utility in > > Cheers, > > Thomas Goirand (zigo) > From allison at openstack.org Wed Nov 11 21:53:09 2020 From: allison at openstack.org (Allison Price) Date: Wed, 11 Nov 2020 15:53:09 -0600 Subject: Victoria Release Community Meeting In-Reply-To: References: Message-ID: <7A81F469-DE61-43FD-A0D2-A9779F9F023E@openstack.org> Let me chat with the OpenDev folks about their Jitsi instance to see what we can do for the next community meeting. > On Nov 11, 2020, at 2:58 PM, Thomas Goirand wrote: > > On 11/11/20 9:06 PM, Allison Price wrote: >> We can definitely consider using Jitsi for the next OIF community >> meeting. One significant feature that Zoom has is our ability to record >> the community meeting so that the rest of the community can watch on >> their own time, accommodating for different time zones. For those who do >> not wish to participate via Zoom tomorrow, the recording will be posted >> on YouTube and all of the PTLs share in their presentation how to >> connect with them via email or IRC. > > This can be done with Jitsi too (but not Jitsi alone). Again, if you > don't know how, I can get you in touch with the Debconf video team. > > Cheers, > > Thomas Goirand (zigo) > From fungi at yuggoth.org Wed Nov 11 21:53:57 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 11 Nov 2020 21:53:57 +0000 Subject: Victoria Release Community Meeting In-Reply-To: References: <1605050603.25113268@apps.rackspace.com> <4c09adb4-0f97-f256-9827-01781643a9c3@debian.org> <10079933.t8I2mb3pXR@p1> <20201111144618.ndckzezqgbb2xble@yuggoth.org> Message-ID: <20201111215357.q4s5y6klgup4d6zh@yuggoth.org> On 2020-11-11 21:58:12 +0100 (+0100), Thomas Goirand wrote: > On 11/11/20 9:06 PM, Allison Price wrote: > > We can definitely consider using Jitsi for the next OIF community > > meeting. One significant feature that Zoom has is our ability to record > > the community meeting so that the rest of the community can watch on > > their own time, accommodating for different time zones. For those who do > > not wish to participate via Zoom tomorrow, the recording will be posted > > on YouTube and all of the PTLs share in their presentation how to > > connect with them via email or IRC. > > This can be done with Jitsi too (but not Jitsi alone). Again, if you > don't know how, I can get you in touch with the Debconf video team. Well, client-side recording is always an option. Server-side recording could be added, the OpenDev sysadmins have discussed it, the challenges are mostly logistical (preallocating all the recording slot processes, deciding where to store and serve recordings, et cetera). The other significant feature we'd need to set up for uses like the OIF community meetings would be dial-in. We pay for a POTS trunk from a SIP broker with an assigned number in the USA for our Asterisk-based pbx.openstack.org service and have talked about reassigning that to meetpad.opendev.org but would need folks with available time to work on doing that. Adding brokers with numbers in other parts of the World may also be an option as long as we can get the okay from the folks paying the bill. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From sean.mcginnis at gmx.com Wed Nov 11 22:38:24 2020 From: sean.mcginnis at gmx.com (Sean McGinnis) Date: Wed, 11 Nov 2020 16:38:24 -0600 Subject: [all] Fixtures & monkey patching issue with Python 3.9 In-Reply-To: <674bfdfb-495a-19e0-a306-b96aece85b14@debian.org> References: <674bfdfb-495a-19e0-a306-b96aece85b14@debian.org> Message-ID: <80a3d4dc-7c58-20bc-c6aa-1b711f610c8e@gmx.com> > Is this affecting OpenStack? Looks like maybe no? https://zuul.opendev.org/t/openstack/builds?job_name=openstack-tox-py39 There are a few py39 failures reported, but of the couple I took a quick look at (nova and ironic) it didn't look like the same signature as the issues referenced. Sean From yumeng_bao at yahoo.com Thu Nov 12 02:59:10 2020 From: yumeng_bao at yahoo.com (yumeng bao) Date: Thu, 12 Nov 2020 10:59:10 +0800 Subject: [cyborg] Propose Wenping Song for Cyborg core References: <4DFC0051-B2DF-40A8-AC1B-5E523681811C.ref@yahoo.com> Message-ID: <4DFC0051-B2DF-40A8-AC1B-5E523681811C@yahoo.com> Hi team, I would like to propose adding Wenping Song to the cyborg-core groups. Wenping did some great work on arq microversion and FPGA new driver support in the Victoria release, and has provided some helpful reviews. Cores - please reply +1/-1 before the end of Wednesday 18th November. Regards， Yumeng From zhangbailin at inspur.com Thu Nov 12 03:17:53 2020 From: zhangbailin at inspur.com (=?utf-8?B?QnJpbiBaaGFuZyjlvKDnmb7mnpcp?=) Date: Thu, 12 Nov 2020 03:17:53 +0000 Subject: =?utf-8?B?562U5aSNOiBbbGlzdHMub3BlbnN0YWNrLm9yZ+S7o+WPkV1bY3lib3JnXSBQ?= =?utf-8?Q?ropose_Wenping_Song_for_Cyborg_core?= In-Reply-To: <4DFC0051-B2DF-40A8-AC1B-5E523681811C@yahoo.com> References: <9a15c7540b4ca66d397ecaf2ce5f4f26@sslemail.net> <4DFC0051-B2DF-40A8-AC1B-5E523681811C@yahoo.com> Message-ID: <1e0fe839da29414d89189f731b6e0e65@inspur.com> +1, a hard working boy, and he will do better and better. brinzhang Inspur Electronic Information Industry Co.,Ltd. -----邮件原件----- 发件人: yumeng bao [mailto:yumeng_bao at yahoo.com] 发送时间: 2020年11月12日 10:59 收件人: openstack maillist 主题: [lists.openstack.org代发][cyborg] Propose Wenping Song for Cyborg core Hi team, I would like to propose adding Wenping Song to the cyborg-core groups. Wenping did some great work on arq microversion and FPGA new driver support in the Victoria release, and has provided some helpful reviews. Cores - please reply +1/-1 before the end of Wednesday 18th November. Regards， Yumeng From zhipengh512 at gmail.com Thu Nov 12 03:31:24 2020 From: zhipengh512 at gmail.com (Zhipeng Huang) Date: Thu, 12 Nov 2020 11:31:24 +0800 Subject: =?UTF-8?Q?Re=3A_=5Blists=2Eopenstack=2Eorg=E4=BB=A3=E5=8F=91=5D=5Bcyborg=5D_Propose_Wenp?= =?UTF-8?Q?ing_Song_for_Cyborg_core?= In-Reply-To: <1e0fe839da29414d89189f731b6e0e65@inspur.com> References: <9a15c7540b4ca66d397ecaf2ce5f4f26@sslemail.net> <4DFC0051-B2DF-40A8-AC1B-5E523681811C@yahoo.com> <1e0fe839da29414d89189f731b6e0e65@inspur.com> Message-ID: +1, Wenping has been working hard during recent releases :) On Thu, Nov 12, 2020 at 11:22 AM Brin Zhang(张百林) wrote: > +1, a hard working boy, and he will do better and better. > > brinzhang > Inspur Electronic Information Industry Co.,Ltd. > > > -----邮件原件----- > 发件人: yumeng bao [mailto:yumeng_bao at yahoo.com] > 发送时间: 2020年11月12日 10:59 > 收件人: openstack maillist > 主题: [lists.openstack.org代发][cyborg] Propose Wenping Song for Cyborg core > > Hi team, > > I would like to propose adding Wenping Song to > the cyborg-core groups. Wenping did some great work on arq microversion and > FPGA new driver support in the Victoria release, and has provided some > helpful reviews. > > Cores - please reply +1/-1 before the end of Wednesday 18th November. > > > Regards， > Yumeng > > -- Zhipeng (Howard) Huang Principle Engineer OpenStack, Kubernetes, CNCF, LF Edge, ONNX, Kubeflow, OpenSDS, Open Service Broker API, OCP, Hyperledger, ETSI, SNIA, DMTF, W3C -------------- next part -------------- An HTML attachment was scrubbed... URL: From xin-ran.wang at intel.com Thu Nov 12 05:21:13 2020 From: xin-ran.wang at intel.com (Wang, Xin-ran) Date: Thu, 12 Nov 2020 05:21:13 +0000 Subject: =?utf-8?B?UkU6IFtsaXN0cy5vcGVuc3RhY2sub3Jn5Luj5Y+RXVtjeWJvcmddIFByb3Bv?= =?utf-8?Q?se_Wenping_Song_for_Cyborg_core?= In-Reply-To: References: <9a15c7540b4ca66d397ecaf2ce5f4f26@sslemail.net> <4DFC0051-B2DF-40A8-AC1B-5E523681811C@yahoo.com> <1e0fe839da29414d89189f731b6e0e65@inspur.com> Message-ID: +1, Wenping has been working hard, , thanks for wenping’s contribution. From: Zhipeng Huang Sent: Thursday, November 12, 2020 11:31 AM To: openstack-discuss at lists.openstack.org Cc: Brin Zhang(张百林) ; yumeng_bao at yahoo.com Subject: Re: [lists.openstack.org代发][cyborg] Propose Wenping Song for Cyborg core +1, Wenping has been working hard during recent releases :) On Thu, Nov 12, 2020 at 11:22 AM Brin Zhang(张百林) > wrote: +1, a hard working boy, and he will do better and better. brinzhang Inspur Electronic Information Industry Co.,Ltd. -----邮件原件----- 发件人: yumeng bao [mailto:yumeng_bao at yahoo.com] 发送时间: 2020年11月12日 10:59 收件人: openstack maillist > 主题: [lists.openstack.org代发][cyborg] Propose Wenping Song for Cyborg core Hi team, I would like to propose adding Wenping Song> to the cyborg-core groups. Wenping did some great work on arq microversion and FPGA new driver support in the Victoria release, and has provided some helpful reviews. Cores - please reply +1/-1 before the end of Wednesday 18th November. Regards， Yumeng -- Zhipeng (Howard) Huang Principle Engineer OpenStack, Kubernetes, CNCF, LF Edge, ONNX, Kubeflow, OpenSDS, Open Service Broker API, OCP, Hyperledger, ETSI, SNIA, DMTF, W3C -------------- next part -------------- An HTML attachment was scrubbed... URL: From themasch at gmx.net Thu Nov 12 05:51:02 2020 From: themasch at gmx.net (MaSch) Date: Thu, 12 Nov 2020 06:51:02 +0100 Subject: multiple nfs shares with cinder-backup In-Reply-To: References: Message-ID: <182661d1-e0d3-f48e-a874-5c520b76a2dc@gmx.net> Hy! Is it possible to set a default value for the container? So that the users don't have to specify them when they create a backup? Lets say, the default value directs to share a, for manually generated Backups, and all automated created Backups have the --container param set for share b. regards, MaSch On 2020-11-10 1:55 p.m., Radosław Piliszek wrote: > On Wed, Nov 4, 2020 at 11:45 AM MaSch wrote: >> Hello all! >> >> I'm currently using openstack queens with cinder 12.0.10. >> I would like to a backend I'm using a NFS-share. >> >> Now i would like to spit my backups up to two nfs-shares. >> I have seen that the cinder.volume.driver can handle multiple nfs shares. >> But it seems that cinder.backup.driver can not. >> >> Is there a way to use two nfs shares for backups? >> Or is it maybe possible with a later release of Cinder? >> >> regards, >> MaSch >> >> > You can use directories where you mount different NFS shares. > Cinder Backup allows you to specify the directory to use for backup so > this way you can segregate the backups. > Just specify --container in your commands. > > -yoctozepto From marios at redhat.com Thu Nov 12 07:44:19 2020 From: marios at redhat.com (Marios Andreou) Date: Thu, 12 Nov 2020 09:44:19 +0200 Subject: [tripleo] stein branch transition to extended maintenance Message-ID: Hello TripleOs The stein branch is about to transition to extended maintenance [1]. This will happen after the proposal at [2] is approved (by us) and merged. The latest release of stein for each of the repos in [2] will be tagged as extended maintenance. We have the option of first making another (final) release, if there is something newer in stein that we need to be included. We will continue to allow for bug fixes to be committed to stein however there will be no more releases made after this point. So, does anyone need a final release made for the stein branch for one of the repos in [3]. If no one speaks up then I will +1 the patch at [2] tomorrow thanks, marios [1] https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases [2] https://review.opendev.org/#/c/762411/ [3] https://releases.openstack.org/teams/tripleo.html#stein -------------- next part -------------- An HTML attachment was scrubbed... URL: From geguileo at redhat.com Thu Nov 12 09:02:48 2020 From: geguileo at redhat.com (Gorka Eguileor) Date: Thu, 12 Nov 2020 10:02:48 +0100 Subject: multiple nfs shares with cinder-backup In-Reply-To: <182661d1-e0d3-f48e-a874-5c520b76a2dc@gmx.net> References: <182661d1-e0d3-f48e-a874-5c520b76a2dc@gmx.net> Message-ID: <20201112090248.e6a5e54jd67tyfqq@localhost> On 12/11, MaSch wrote: > Hy! > > Is it possible to set a default value for the container? > So that the users don't have to specify them when they create a backup? > Lets say, the default value directs to share a, for manually generated > Backups, > and all automated created Backups have the --container param set for > share b. > > regards, > MaSch Hi, The "backup_container" configuration option allows you to set the default container. Cheers, Gorka. > > On 2020-11-10 1:55 p.m., Radosław Piliszek wrote: > > On Wed, Nov 4, 2020 at 11:45 AM MaSch wrote: > > > Hello all! > > > > > > I'm currently using openstack queens with cinder 12.0.10. > > > I would like to a backend I'm using a NFS-share. > > > > > > Now i would like to spit my backups up to two nfs-shares. > > > I have seen that the cinder.volume.driver can handle multiple nfs shares. > > > But it seems that cinder.backup.driver can not. > > > > > > Is there a way to use two nfs shares for backups? > > > Or is it maybe possible with a later release of Cinder? > > > > > > regards, > > > MaSch > > > > > > > > You can use directories where you mount different NFS shares. > > Cinder Backup allows you to specify the directory to use for backup so > > this way you can segregate the backups. > > Just specify --container in your commands. > > > > -yoctozepto > From eblock at nde.ag Thu Nov 12 09:16:19 2020 From: eblock at nde.ag (Eugen Block) Date: Thu, 12 Nov 2020 09:16:19 +0000 Subject: Cannot deploly an instance at a specific host --(no such host found) [nova] In-Reply-To: References: <20201111132022.Horde.q9K8xVfq2klzzypYBltanTa@webmail.nde.ag> <20201111140328.Horde.e4UaBmIP6Q_GOnn4VutjAea@webmail.nde.ag> Message-ID: <20201112091619.Horde.16cjrNDJAI_5LCsfMauhMaK@webmail.nde.ag> Did you change the transport_url only in the nova.conf of the new compute node? Or did you also change the rabbitmq configuration? The transport_url should match the actual rabbitmq config, of course, and it should be the same on every node. Does that match your cell setup? To compare run: control:~ # nova-manage cell_v2 list_cells --verbose Do you have a vhost configuration? (I'm not familiar with devstack) Here's an example of a "nova" vhost with respective permissions: control:~ # rabbitmqctl list_vhosts Listing vhosts / nova control:~ # rabbitmqctl list_permissions -p nova Listing permissions in vhost "nova" nova .* .* .* If there's a vhost it should be also reflected in the transport_url. Maybe you should share all of the above information here. Zitat von Pavlos Basaras : > Hello, > > maybe there is stg wrong with the installation. > > Let me clarify a few things. > > I have devstack deployed in a VM (pre-installed: keystone, glance, nova, > placement, cinder, neutron, and horizon.) > I can deploy machines successfully at the devstack controller space > --everything seems to work fine. --> is seems to work fine with opensource > mano as well > > I am trying to add another pc as a compute host to be able to deploy vms at > this new compute host following ( > https://docs.openstack.org/nova/queens/install/compute-install-ubuntu.html) > > Also attached the nova.conf file. The only major differences are: > --the transport url for rabbitmq which i made according to the transport > url of the controller, i.e., instead of rabbit://openstack:linux at controller > i have rabbit://stackrabbit:linux at controller > -- i replaced the ports with the service, e.g., instead using the 5000 port > --> "http://controller/identity/v3" instead of "http://controller:5000/v3" > > please excuse (any) newbie questions > > all the best, > Pavlos. > > > On Wed, Nov 11, 2020 at 4:03 PM Eugen Block wrote: > >> There might be some mixup during the setup, I'm not sure how the other >> cell would be created. I'd probably delete the cell with UUID >> 1a0fde85-8906-46fb-b721-01a28c978439 and retry the discover_hosts with >> the right cell UUID: >> >> nova-manage cell_v2 delete_cell --cell_uuid >> 1a0fde85-8906-46fb-b721-01a28c978439 >> nova-manage cell_v2 discover_hosts --cell_uuid >> 1522c22f-64d4-4882-8ae8-ed0f9407407c >> >> Does that work? >> >> >> Zitat von Pavlos Basaras : >> >> > Hello, >> > >> > yes i have this discover_hosts_in_cells_interval = 300 >> > >> > >> > interestingly when i issued a combination of map_cell_and_hosts and >> > update_cell >> > >> > the output from: nova-manage cell_v2 list_hosts >> > +-----------+--------------------------------------+-------------+ >> > | Cell Name | Cell UUID | Hostname | >> > +-----------+--------------------------------------+-------------+ >> > | None | 1a0fde85-8906-46fb-b721-01a28c978439 | computenode | >> > | None | 1a0fde85-8906-46fb-b721-01a28c978439 | nrUE | >> > | cell1 | 1522c22f-64d4-4882-8ae8-ed0f9407407c | openstack | >> > +-----------+--------------------------------------+-------------+ >> > >> > when the new compute nodes seem to not have a cell mapped >> > >> > best, >> > P. >> > >> > >> > On Wed, Nov 11, 2020 at 3:26 PM Eugen Block wrote: >> > >> >> Hm, >> >> >> >> indeed rather strange to me. >> >> >> >> Do you see anything in the nova-scheduler.log? If you activated the >> >> >> >> discover_hosts_in_cells_interval = 300 >> >> >> >> it should query for new hosts every 5 minutes. >> >> >> >> >> >> >> >> Zitat von Pavlos Basaras : >> >> >> >> > Hello, >> >> > >> >> > thanks very much for your prompt reply. >> >> > >> >> > >> >> > regarding the first command "nova-manage cell_v2 list_hosts" the >> output >> >> is >> >> > the following (openstack is the host of the controller). I dont see >> any >> >> > other node here, even when i execute the discover_hosts command >> >> > >> >> > +-----------+--------------------------------------+-----------+ >> >> > | Cell Name | Cell UUID | Hostname | >> >> > +-----------+--------------------------------------+-----------+ >> >> > | cell1 | 1522c22f-64d4-4882-8ae8-ed0f9407407c | openstack | >> >> > +-----------+--------------------------------------+-----------+ >> >> > >> >> > >> >> > Also this is the output from my controller when i use the command: >> sudo >> >> -s >> >> > /bin/sh -c "nova-manage cell_v2 discover_hosts --verbose" nova (not >> >> sure >> >> > if this helps) >> >> > Found 2 cell mappings. >> >> > Skipping cell0 since it does not contain hosts. >> >> > Getting computes from cell 'cell1': >> 1522c22f-64d4-4882-8ae8-ed0f9407407c >> >> > Found 0 unmapped computes in cell: >> 1522c22f-64d4-4882-8ae8-ed0f9407407c >> >> > >> >> > any thoughts? >> >> > >> >> > >> >> > best, >> >> > Pavlos. >> >> >> >> >> >> >> >> >> >> >> >> >> >> From noonedeadpunk at ya.ru Thu Nov 12 09:18:04 2020 From: noonedeadpunk at ya.ru (Dmitriy Rabotyagov) Date: Thu, 12 Nov 2020 11:18:04 +0200 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: Message-ID: <4211161605171577@mail.yandex.ru> An HTML attachment was scrubbed... URL: From jahson.babel at cc.in2p3.fr Thu Nov 12 09:24:30 2020 From: jahson.babel at cc.in2p3.fr (Babel Jahson) Date: Thu, 12 Nov 2020 10:24:30 +0100 Subject: [Manila] Manila user overwriting existing Ceph users Message-ID: <951ce1de-c915-5faa-b203-cb2b02f21b08@cc.in2p3.fr> Hello everyone, I'm currently testing manila with CephFS and I stumbled upon a behavior where manila is able to overwrite existing Ceph users. In my testing setup glance, nova, cinder and manila share the same Ceph cluster. However they have different users. In this situation when you create a share and allow acces via "manila access-allow cephshare1 cephx test" If the user "test" is already used to access some pools on the cluster, let's say cinder-volume or glance-images it will be overwritten with the permissions for the share. Which will break any resources that was using it. I've recheck the configuration files multiple times to see if I could set some properties to avoid this but I didn't find any. By quickly looking at the code here : https://opendev.org/openstack/manila/src/branch/master/manila/share/drivers/cephfs/driver.py A check is done but only for the manila user. I'm on Rocky version but this part doesn't seems to have changed since. That lead me to some questions : - Does manila must have his own dedicated Ceph cluster ? - Is there any workaroud to this ? Other than putting some gibberish names for services users ? - Is it possible to lock some users in the Ceph cluster to prevent this behavior ? If someone has some clues on this, thanks in advance. Jahson.B -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrunge at matthias-runge.de Thu Nov 12 10:25:09 2020 From: mrunge at matthias-runge.de (Matthias Runge) Date: Thu, 12 Nov 2020 11:25:09 +0100 Subject: [telemetry] wallaby cycle planning session Message-ID: Hi there, one of the biggest challenges for the telemetry stack is currently the state of gnocchi, which is... undefined/unfortunate/under-contributed/...? Telemetry started long time ago as a simple component ceilometer, which was split into several components ceilometer, aodh, panko, and gnocchi. Julien wrote a story about this some time ago[1]. There has also been an attempt to fork gnocchi back to OpenStack[2]. To my knowledge, the original contributors are not paid anymore to work on gnocchi, and at the same time, moving on to do something else is totally fine. However, I am not sure if we (in OpenStack Telemetry) should or could maintain in addition to the rest of the telemetry stack a time-series database. I'd like to discuss this during a call. Please select time(s) that suit you best in this poll[3]. If you have questions or hints, don't hesitate to contact me. Thank you, Matthias [1] https://julien.danjou.info/lessons-from-openstack-telemetry-deflation/ [2] https://review.opendev.org/#/c/744592/ [3] https://doodle.com/poll/uqq328x5shr43awy From thierry at openstack.org Thu Nov 12 10:29:11 2020 From: thierry at openstack.org (Thierry Carrez) Date: Thu, 12 Nov 2020 11:29:11 +0100 Subject: [tc][all][searchlight ] Retiring the Searchlight project In-Reply-To: <175b44e80fd.f4c0ee8420790.4317890968302424842@ghanshyammann.com> References: <175b3960913.120cf390316504.5945799248975474230@ghanshyammann.com> <297cf22b-2172-cb51-f282-4c0e674a9a07@debian.org> <175b44e80fd.f4c0ee8420790.4317890968302424842@ghanshyammann.com> Message-ID: <7e1e40f2-afeb-ebcb-6faa-b3b7534a8039@openstack.org> Ghanshyam Mann wrote: > Yes, as part of the retirement process all deliverables under the project needs to be removed > and before removal we do: > 1. Remove all dependencies. > 2. Refactor/remove the gate job dependency also. > 3. Remove the code from the retiring repo. I think Thomas's point was that some of those retired deliverables are required by non-retired deliverables, like: - python-qinlingclient being required by mistral-extra - python-searchlightclient and python-karborclient being required by openstackclient and python-openstackclient We might need to remove those features/dependencies first, which might take time... -- Thierry Carrez (ttx) From gfidente at redhat.com Thu Nov 12 10:56:44 2020 From: gfidente at redhat.com (Giulio Fidente) Date: Thu, 12 Nov 2020 11:56:44 +0100 Subject: [Manila] Manila user overwriting existing Ceph users In-Reply-To: <951ce1de-c915-5faa-b203-cb2b02f21b08@cc.in2p3.fr> References: <951ce1de-c915-5faa-b203-cb2b02f21b08@cc.in2p3.fr> Message-ID: On 11/12/20 10:24 AM, Babel Jahson wrote: > Hello everyone, > > I'm currently testing manila with CephFS and I stumbled upon a behavior > where manila is able to overwrite existing Ceph users. > In my testing setup glance, nova, cinder and manila share the same Ceph > cluster. However they have different users. > In this situation when you create a share and allow acces via "manila > access-allow cephshare1 cephx test" > If the user "test" is already used to access some pools on the cluster, > let's say cinder-volume or glance-images it will be overwritten with the > permissions for the share. > Which will break any resources that was using it. > I've recheck the configuration files multiple times to see if I could > set some properties to avoid this but I didn't find any. > By quickly looking at the code here : > https://opendev.org/openstack/manila/src/branch/master/manila/share/drivers/cephfs/driver.py > A check is done but only for the manila user. I'm on Rocky version but > this part doesn't seems to have changed since. > > That lead me to some questions : > - Does manila must have his own dedicated Ceph cluster ? > - Is there any workaroud to this ? Other than putting some gibberish > names for services users ? > - Is it possible to lock some users in the Ceph cluster to prevent this > behavior ? hi Jahnson, I am adding a few folks who can probably help us better but I also wanted to ask a question to understand better the use case the cephx user which cinder/glance/nova use has specific permissions to operate on their pools and this is configured in their respective config, not something you have access from the actual openstack guests; are you saying that "access-allow" is overwriting the cephx caps which were set for the cephx user which, for example, cinder is configured to use? in that case maybe better would be for the manila workflow to add/remove caps to existing users instead of overwriting the caps? is that be what you expected to happen? -- Giulio Fidente GPG KEY: 08D733BA From jpena at redhat.com Thu Nov 12 11:09:20 2020 From: jpena at redhat.com (Javier Pena) Date: Thu, 12 Nov 2020 06:09:20 -0500 (EST) Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: Message-ID: <864396842.58157343.1605179360197.JavaMail.zimbra@redhat.com> > On 11/11/20 5:35 PM, Balázs Gibizer wrote: > > Dear packagers and deployment engine developers, > > > > Since Icehouse nova-compute service does not need any database > > configuration as it uses the message bus to access data in the database > > via the conductor service. Also, the nova configuration guide states > > that the nova-compute service should not have the > > [api_database]connection config set. Having any DB credentials > > configured for the nova-compute is a security risk as well since that > > service runs close to the hypervisor. Since Rocky[1] nova-compute > > service fails if you configure API DB credentials and set upgrade_level > > config to 'auto'. > > > > Now we are proposing a patch[2] that makes nova-compute fail at startup > > if the [database]connection or the [api_database]connection is > > configured. We know that this breaks at least the rpm packaging, debian > > packaging, and puppet-nova. The problem there is that in an all-in-on > > deployment scenario the nova.conf file generated by these tools is > > shared between all the nova services and therefore nova-compute sees DB > > credentials. As a counter-example, devstack generates a separate > > nova-cpu.conf and passes that to the nova-compute service even in an > > all-in-on setup. > > > > The nova team would like to merge [2] during Wallaby but we are OK to > > delay the patch until Wallaby Milestone 2 so that the packagers and > > deployment tools can catch up. Please let us know if you are impacted > > and provide a way to track when you are ready with the modification that > > allows [2] to be merged. > > > > There was a long discussion on #openstack-nova today[3] around this > > topic. So you can find more detailed reasoning there[3]. > > > > Cheers, > > gibi > > IMO, that's ok if, and only if, we all agree on how to implement it. > Best would be if we (all downstream distro + config management) agree on > how to implement this. > > How about, we all implement a /etc/nova/nova-db.conf, and get all > services that need db access to use it (ie: starting them with > --config-file=/etc/nova/nova-db.conf)? > Hi, This is going to be an issue for those services we run as a WSGI app. Looking at [1], I see the app has a hardcoded list of config files to read (api-paste.ini and nova.conf), so we'd need to modify it at the installer level. Personally, I like the nova-db.conf way, since it looks like it reduces the amount of work required for all-in-one installers to adapt, but that requires some code change. Would the Nova team be happy with adding a nova-db.conf file to that list? Regards, Javier [1] - https://opendev.org/openstack/nova/src/branch/master/nova/api/openstack/wsgi_app.py#L30 > If I understand well, these services would need access to db: > - conductor > - scheduler > - novncproxy > - serialproxy > - spicehtml5proxy > - api > - api-metadata > > Is this list correct? Or is there some services that also don't need it? > > Cheers, > > Thomas Goirand (zigo) > > From ekuvaja at redhat.com Thu Nov 12 12:23:49 2020 From: ekuvaja at redhat.com (Erno Kuvaja) Date: Thu, 12 Nov 2020 12:23:49 +0000 Subject: [swift]: issues with multi region (swift as backend for glance) In-Reply-To: <46812675.2700917.1604706323822@mail.yahoo.com> References: <46812675.2700917.1604706323822.ref@mail.yahoo.com> <46812675.2700917.1604706323822@mail.yahoo.com> Message-ID: On Fri, Nov 6, 2020 at 11:49 PM fsbiz at yahoo.com wrote: > Hi folks, > > We're on queens release. > > We have just setup a 2nd region. So, now we have two regions regionOne > and regionTwo > > We had a storage cluster in regionOne. Everything works good. > We also added another storage cluster in regionTwo and have created swift > endpoints for this. > Using swift API, everything works fine. The container is properly created > in regionOne or regionTwo as > desired. > > > > We are also using swift as the glance backend. We are seeing an issue > with this for regionTwo. > When I create an image in regionTwo, it seems like the glance storage > backend is not properly recognizing > the endpoint and wants to store the image in regionOne. > > This looks like a definite bug. > I can work around it by overriding the endpoint using swift_store_endpoint > but if there is a known bug > about this issue I would rather patch it than resort to overriding the URL > endpoint returned from "auth". > > Is this a known bug ? Again, we are on the latest Queens release. > > thanks, > Fred. > > Hi Fred, With these details I'm not exactly sure what the bug would be here. Glance has no concept for availability zones or regions per se. It expects consistent database across the deployment and multi-store not being a thing in Queens yet, there really is no meaningful way to configure multiple instances of the same store type. While there is no enforcement of homogenous configuration across the Glance nodes, the storage side really depends on it for the service to operate correctly. Forcing Glance to use different stores with the same database will likely cause lots of confusion and poor user experience. I'd assume that to achieve what you are looking for you'd either need to upgrade your openstack deployment to recent version to take advantage of the multi-store work or use separate Glance deployments per region. best, Erno "jokke" Kuvaja -------------- next part -------------- An HTML attachment was scrubbed... URL: From jahson.babel at cc.in2p3.fr Thu Nov 12 12:32:39 2020 From: jahson.babel at cc.in2p3.fr (Babel Jahson) Date: Thu, 12 Nov 2020 13:32:39 +0100 Subject: [Manila] Manila user overwriting existing Ceph users In-Reply-To: References: <951ce1de-c915-5faa-b203-cb2b02f21b08@cc.in2p3.fr> Message-ID: Hi Giulio, Thank you for your response. > the cephx user which cinder/glance/nova use has specific permissions to > operate on their pools and this is configured in their respective > config, not something you have access from the actual openstack guests; > are you saying that "access-allow" is overwriting the cephx caps which > were set for the cephx user which, for example, cinder is configured to use? Yes a cinder user can be overwritten in the Ceph config cluster by the command "access-allow" to a share. Basically it goes from something like this : [client.cindertest]     key =     caps mon = "profile rbd"     caps osd = "profile rbd pool=some-pool, profile rbd pool=some-pool To something like that : [client.cindertest]     key =     caps mds = "allow rw path=/volumes/_nogroup/"     caps mon = "allow r"     caps osd = "allow rw pool= namespace=fsvolumens_" Which can be problematic. > in that case maybe better would be for the manila workflow to add/remove > caps to existing users instead of overwriting the caps? is that be what > you expected to happen? Not really, I mean it's a possibility but is it safe to just add those caps to an existing user ? Won't that interfere with something else ? A way to prevent the creation of a user like "cindertest" seems a better solution to me but I maybe wrong. It's behavior manila already has. If a user have been created with manila for a share in a project and you ask for that user in another project in openstack it wouldn't let you used it. Jahson On 12/11/2020 11:56, Giulio Fidente wrote: > On 11/12/20 10:24 AM, Babel Jahson wrote: >> Hello everyone, >> >> I'm currently testing manila with CephFS and I stumbled upon a behavior >> where manila is able to overwrite existing Ceph users. >> In my testing setup glance, nova, cinder and manila share the same Ceph >> cluster. However they have different users. >> In this situation when you create a share and allow acces via "manila >> access-allow cephshare1 cephx test" >> If the user "test" is already used to access some pools on the cluster, >> let's say cinder-volume or glance-images it will be overwritten with the >> permissions for the share. >> Which will break any resources that was using it. >> I've recheck the configuration files multiple times to see if I could >> set some properties to avoid this but I didn't find any. >> By quickly looking at the code here : >> https://opendev.org/openstack/manila/src/branch/master/manila/share/drivers/cephfs/driver.py >> A check is done but only for the manila user. I'm on Rocky version but >> this part doesn't seems to have changed since. >> >> That lead me to some questions : >> - Does manila must have his own dedicated Ceph cluster ? >> - Is there any workaroud to this ? Other than putting some gibberish >> names for services users ? >> - Is it possible to lock some users in the Ceph cluster to prevent this >> behavior ? > hi Jahnson, I am adding a few folks who can probably help us better but > I also wanted to ask a question to understand better the use case > > the cephx user which cinder/glance/nova use has specific permissions to > operate on their pools and this is configured in their respective > config, not something you have access from the actual openstack guests; > are you saying that "access-allow" is overwriting the cephx caps which > were set for the cephx user which, for example, cinder is configured to use? > > in that case maybe better would be for the manila workflow to add/remove > caps to existing users instead of overwriting the caps? is that be what > you expected to happen? From amotoki at gmail.com Thu Nov 12 12:42:48 2020 From: amotoki at gmail.com (Akihiro Motoki) Date: Thu, 12 Nov 2020 21:42:48 +0900 Subject: [tc][all][searchlight ] Retiring the Searchlight project In-Reply-To: <7e1e40f2-afeb-ebcb-6faa-b3b7534a8039@openstack.org> References: <175b3960913.120cf390316504.5945799248975474230@ghanshyammann.com> <297cf22b-2172-cb51-f282-4c0e674a9a07@debian.org> <175b44e80fd.f4c0ee8420790.4317890968302424842@ghanshyammann.com> <7e1e40f2-afeb-ebcb-6faa-b3b7534a8039@openstack.org> Message-ID: On Thu, Nov 12, 2020 at 7:31 PM Thierry Carrez wrote: > > Ghanshyam Mann wrote: > > Yes, as part of the retirement process all deliverables under the project needs to be removed > > and before removal we do: > > 1. Remove all dependencies. > > 2. Refactor/remove the gate job dependency also. > > 3. Remove the code from the retiring repo. > > I think Thomas's point was that some of those retired deliverables are > required by non-retired deliverables, like: > > - python-qinlingclient being required by mistral-extra > > - python-searchlightclient and python-karborclient being required by > openstackclient and python-openstackclient > > We might need to remove those features/dependencies first, which might > take time... Yeah, I think so too. Regarding OSC, python-openstackclient does not depend on python-searchlightclient. "openstackclient" is a wrapper project which allows us to install all OSC plugins along with the main OSC. We can drop retired OSC plugins from the "openstackclient" requirements. -- Akihiro Motoki (irc: amotoki) > > -- > Thierry Carrez (ttx) > From tpb at dyncloud.net Thu Nov 12 13:30:39 2020 From: tpb at dyncloud.net (Tom Barron) Date: Thu, 12 Nov 2020 08:30:39 -0500 Subject: [Manila] Manila user overwriting existing Ceph users In-Reply-To: References: <951ce1de-c915-5faa-b203-cb2b02f21b08@cc.in2p3.fr> Message-ID: <20201112133039.ptcjspqgyxkkabn7@barron.net> On 12/11/20 13:32 +0100, Babel Jahson wrote: >Hi Giulio, > >Thank you for your response. > >>the cephx user which cinder/glance/nova use has specific permissions to >>operate on their pools and this is configured in their respective >>config, not something you have access from the actual openstack guests; >>are you saying that "access-allow" is overwriting the cephx caps which >>were set for the cephx user which, for example, cinder is configured to use? >Yes a cinder user can be overwritten in the Ceph config cluster by the >command "access-allow" to a share. >Basically it goes from something like this : >[client.cindertest] >    key = >    caps mon = "profile rbd" >    caps osd = "profile rbd pool=some-pool, profile rbd pool=some-pool > >To something like that : >[client.cindertest] >    key = >    caps mds = "allow rw path=/volumes/_nogroup/" >    caps mon = "allow r" >    caps osd = "allow rw pool= namespace=fsvolumens_" > >Which can be problematic. > >>in that case maybe better would be for the manila workflow to add/remove >>caps to existing users instead of overwriting the caps? is that be what >>you expected to happen? >Not really, I mean it's a possibility but is it safe to just add those >caps to an existing user ? Won't that interfere with something else ? >A way to prevent the creation of a user like "cindertest" seems a >better solution to me but I maybe wrong. >It's behavior manila already has. If a user have been created with >manila for a share in a project and you ask for that user in another >project in openstack it wouldn't let you used it. > >Jahson > >On 12/11/2020 11:56, Giulio Fidente wrote: >>On 11/12/20 10:24 AM, Babel Jahson wrote: >>>Hello everyone, >>> >>>I'm currently testing manila with CephFS and I stumbled upon a behavior >>>where manila is able to overwrite existing Ceph users. >>>In my testing setup glance, nova, cinder and manila share the same Ceph >>>cluster. However they have different users. >>>In this situation when you create a share and allow acces via "manila >>>access-allow cephshare1 cephx test" >>>If the user "test" is already used to access some pools on the cluster, >>>let's say cinder-volume or glance-images it will be overwritten with the >>>permissions for the share. >>>Which will break any resources that was using it. >>>I've recheck the configuration files multiple times to see if I could >>>set some properties to avoid this but I didn't find any. >>>By quickly looking at the code here : >>>https://opendev.org/openstack/manila/src/branch/master/manila/share/drivers/cephfs/driver.py >>>A check is done but only for the manila user. I'm on Rocky version but >>>this part doesn't seems to have changed since. >>> >>>That lead me to some questions : >>>- Does manila must have his own dedicated Ceph cluster ? >>>- Is there any workaroud to this ? Other than putting some gibberish >>>names for services users ? >>>- Is it possible to lock some users in the Ceph cluster to prevent this >>>behavior ? >>hi Jahnson, I am adding a few folks who can probably help us better but >>I also wanted to ask a question to understand better the use case >> >>the cephx user which cinder/glance/nova use has specific permissions to >>operate on their pools and this is configured in their respective >>config, not something you have access from the actual openstack guests; >>are you saying that "access-allow" is overwriting the cephx caps which >>were set for the cephx user which, for example, cinder is configured to use? >> >>in that case maybe better would be for the manila workflow to add/remove >>caps to existing users instead of overwriting the caps? is that be what >>you expected to happen? > Babel, Thanks for this report. Would you be so kind as to open a Launchpad bug against Manila for this issue? Manila, Nova, Cinder, etc. all use the same Ceph cluster but use different pools in that cluster. It does seem that we need the CephFS driver (or perhaps something in the Ceph cluster) to mark the service users as such and prevent changes to them by Manila. -- Tom Barron From ekuvaja at redhat.com Thu Nov 12 13:38:11 2020 From: ekuvaja at redhat.com (Erno Kuvaja) Date: Thu, 12 Nov 2020 13:38:11 +0000 Subject: Victoria Release Community Meeting In-Reply-To: <4c09adb4-0f97-f256-9827-01781643a9c3@debian.org> References: <1605050603.25113268@apps.rackspace.com> <4c09adb4-0f97-f256-9827-01781643a9c3@debian.org> Message-ID: On Wed, Nov 11, 2020 at 11:19 AM Thomas Goirand wrote: > On 11/11/20 12:23 AM, helena at openstack.org wrote: > > The meeting will be held via Zoom. > > Could we *PLEASE* stop the Zoom non-sense? > > Zoom is: > - known to have a poor security record > - imposes the install of the desktop non-free app (yes I know, in some > cases, it is supposed to work without it, but so far it didn't work for me) > - controlled by a 3rd party we cannot trust > > It's not as if we had no alternatives. Jitsi works perfectly and was > used successfully for the whole of debconf, with voctomix and stuff, so > viewers can read a normal live video stream... > > If the foundation doesn't know how to do it, I can put people in touch > with the Debian video team. I'm sure they will be helpful. > > Cheers, > > Thomas Goirand (zigo) > > Very much this, please. There are plenty of options out there and yet we _choose_ time after time to use the one that is not open source and has admitted neglecting their security and privacy issues; and effectively forces the usage of their application (I've yet to get into session without it like Thomas pointed out.) I know Zoom managed to put themselves on top of the hype wave when this COVID-19 mess started, but we should be able to do better than jumping on every single hype train out there. - Erno "jokke" Kuvaja -------------- next part -------------- An HTML attachment was scrubbed... URL: From jahson.babel at cc.in2p3.fr Thu Nov 12 13:44:41 2020 From: jahson.babel at cc.in2p3.fr (Babel Jahson) Date: Thu, 12 Nov 2020 14:44:41 +0100 Subject: [Manila] Manila user overwriting existing Ceph users In-Reply-To: <20201112133039.ptcjspqgyxkkabn7@barron.net> References: <951ce1de-c915-5faa-b203-cb2b02f21b08@cc.in2p3.fr> <20201112133039.ptcjspqgyxkkabn7@barron.net> Message-ID: <94bfd064-980e-9a6a-09d7-feb56071980d@cc.in2p3.fr> Hi Tom, No problem, I'll create a Launchpadd issue for this. Jahson On 12/11/2020 14:30, Tom Barron wrote: > On 12/11/20 13:32 +0100, Babel Jahson wrote: >> Hi Giulio, >> >> Thank you for your response. >> >>> the cephx user which cinder/glance/nova use has specific permissions to >>> operate on their pools and this is configured in their respective >>> config, not something you have access from the actual openstack guests; >>> are you saying that "access-allow" is overwriting the cephx caps which >>> were set for the cephx user which, for example, cinder is configured >>> to use? >> Yes a cinder user can be overwritten in the Ceph config cluster by >> the command "access-allow" to a share. >> Basically it goes from something like this : >> [client.cindertest] >>     key = >>     caps mon = "profile rbd" >>     caps osd = "profile rbd pool=some-pool, profile rbd pool=some-pool >> >> To something like that : >> [client.cindertest] >>     key = >>     caps mds = "allow rw path=/volumes/_nogroup/" >>     caps mon = "allow r" >>     caps osd = "allow rw pool= >> namespace=fsvolumens_" >> >> Which can be problematic. >> >>> in that case maybe better would be for the manila workflow to >>> add/remove >>> caps to existing users instead of overwriting the caps? is that be what >>> you expected to happen? >> Not really, I mean it's a possibility but is it safe to just add >> those caps to an existing user ? Won't that interfere with something >> else ? >> A way to prevent the creation of a user like "cindertest" seems a >> better solution to me but I maybe wrong. >> It's behavior manila already has. If a user have been created with >> manila for a share in a project and you ask for that user in another >> project in openstack it wouldn't let you used it. >> >> Jahson >> >> On 12/11/2020 11:56, Giulio Fidente wrote: >>> On 11/12/20 10:24 AM, Babel Jahson wrote: >>>> Hello everyone, >>>> >>>> I'm currently testing manila with CephFS and I stumbled upon a >>>> behavior >>>> where manila is able to overwrite existing Ceph users. >>>> In my testing setup glance, nova, cinder and manila share the same >>>> Ceph >>>> cluster. However they have different users. >>>> In this situation when you create a share and allow acces via "manila >>>> access-allow cephshare1 cephx test" >>>> If the user "test" is already used to access some pools on the >>>> cluster, >>>> let's say cinder-volume or glance-images it will be overwritten >>>> with the >>>> permissions for the share. >>>> Which will break any resources that was using it. >>>> I've recheck the configuration files multiple times to see if I could >>>> set some properties to avoid this but I didn't find any. >>>> By quickly looking at the code here : >>>> https://opendev.org/openstack/manila/src/branch/master/manila/share/drivers/cephfs/driver.py >>>> >>>> A check is done but only for the manila user. I'm on Rocky version but >>>> this part doesn't seems to have changed since. >>>> >>>> That lead me to some questions : >>>> - Does manila must have his own dedicated Ceph cluster ? >>>> - Is there any workaroud to this ? Other than putting some gibberish >>>> names for services users ? >>>> - Is it possible to lock some users in the Ceph cluster to prevent >>>> this >>>> behavior ? >>> hi Jahnson, I am adding a few folks who can probably help us better but >>> I also wanted to ask a question to understand better the use case >>> >>> the cephx user which cinder/glance/nova use has specific permissions to >>> operate on their pools and this is configured in their respective >>> config, not something you have access from the actual openstack guests; >>> are you saying that "access-allow" is overwriting the cephx caps which >>> were set for the cephx user which, for example, cinder is configured >>> to use? >>> >>> in that case maybe better would be for the manila workflow to >>> add/remove >>> caps to existing users instead of overwriting the caps? is that be what >>> you expected to happen? >> > > Babel, > > Thanks for this report.  Would you be so kind as to open a Launchpad > bug against Manila for this issue? > > Manila, Nova, Cinder, etc. all use the same Ceph cluster but use > different pools in that cluster.  It does seem that we need the CephFS > driver (or perhaps something in the Ceph cluster) to mark the service > users as such and prevent changes to them by Manila. > > -- Tom Barron > From laszlo.budai at gmail.com Thu Nov 12 13:57:04 2020 From: laszlo.budai at gmail.com (Budai Laszlo) Date: Thu, 12 Nov 2020 15:57:04 +0200 Subject: Queens steal time [nova] Message-ID: <91f41182-bf21-659e-5204-ccd83f535694@gmail.com> Hello all, we are comparing the behavior of our queens  openstack with kilo. In queens we are observing an increase in the steal time reported in the guest along with the increase of the load averages. All this is happening while the host is not overloaded, and reports 80+ idle time Initially we have suspected that the overcommit might be the reason of the steal, so we have migrated vms, and now there are 42 vCPUs used out of the 48 pCPUs, but in the guest we still observe the steal time. with similar configuration in openstack kilo we see smaller load, and almost no steal time at all. what could be the reason of this steal time when there is no CPU overcommit? Thank you for any ideas. Kind regards, Laszlo -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Thu Nov 12 14:26:24 2020 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Thu, 12 Nov 2020 08:26:24 -0600 Subject: [tc][all][searchlight ] Retiring the Searchlight project In-Reply-To: <7e1e40f2-afeb-ebcb-6faa-b3b7534a8039@openstack.org> References: <175b3960913.120cf390316504.5945799248975474230@ghanshyammann.com> <297cf22b-2172-cb51-f282-4c0e674a9a07@debian.org> <175b44e80fd.f4c0ee8420790.4317890968302424842@ghanshyammann.com> <7e1e40f2-afeb-ebcb-6faa-b3b7534a8039@openstack.org> Message-ID: <175bcd9aff4.113c1c86d111248.6965557136678718673@ghanshyammann.com> ---- On Thu, 12 Nov 2020 04:29:11 -0600 Thierry Carrez wrote ---- > Ghanshyam Mann wrote: > > Yes, as part of the retirement process all deliverables under the project needs to be removed > > and before removal we do: > > 1. Remove all dependencies. > > 2. Refactor/remove the gate job dependency also. > > 3. Remove the code from the retiring repo. > > I think Thomas's point was that some of those retired deliverables are > required by non-retired deliverables, like: > > - python-qinlingclient being required by mistral-extra > > - python-searchlightclient and python-karborclient being required by > openstackclient and python-openstackclient > > We might need to remove those features/dependencies first, which might > take time... Yes, that is part of the retirement process, before we remove the project code all dependencies will be taken care same way we did in past (congress project etc). Few dependencies like from OSC it is easy but few like integrated features can be complex and will take time. -gmann > > -- > Thierry Carrez (ttx) > > From rosmaita.fossdev at gmail.com Thu Nov 12 14:57:20 2020 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Thu, 12 Nov 2020 09:57:20 -0500 Subject: [cinder] python-cinderclient: API v2 support removed in Wallaby Message-ID: <73f3c4b6-4040-d2a0-ff78-228645b586af@gmail.com> As announced previously on this mailing list [0], at yesterday's Cinder meeting the Cinder team discussed the timeline for removing Block Storage API v2 support from the python-cinderclient. The Block Storage API v2, which has been deprecated since Pike, will not be present in the OpenStack Wallaby release. The team decided not to delay removing Block Storage API v2 support from the python-cinderclient. Thus, v2 support will *not* be available in the Wallaby python-cinderclient. Given the long deprecation period, we trust that this will not adversely impact too many users. We point out that microversion 3.0 of the Block Storage API v3 is functionally identical to v2; thus scripts that rely on v2 responses should continue to work with minimal changes. We also point out that v3 has been available since Mitaka and has reached microversion 3.62 with the Victoria release; thus it may be worth re-examining such scripts to see what functionality you are missing out on. This email serves both as an announcement and a final call for comments about this proposal. Please reply to this email thread with any comments before next week's Cinder meeting (Wednesday 18 November 2020). Thank you, brian [0] http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018531.html From ankelezhang at gmail.com Thu Nov 12 07:13:01 2020 From: ankelezhang at gmail.com (Ankele zhang) Date: Thu, 12 Nov 2020 15:13:01 +0800 Subject: Ironic use shellinabox doesn't work Message-ID: Hello~ I have a OpenStack platform( Rocky ) on CentOS7.6, and I installed Ironic components on it. I can manage bare metal node with Ironic and I plan to use shellinabox to manage the bare metal node remotely. I had config conductor ironic.conf: [DEFAULT] ... enabled_console_interfaces = ipmitool-shellinabox,no-console I had config shellinabox: USER=shellinabox GROUP=shellinabox CERTDIR=/var/lib/shellinabox PORT=4200 OPTS="--disable-ssl-menu -s /:LOGIN" My 'openstack baremetal node console show BM01': console_enabled: True and console_info.url: http://192.168.3.84:8023 [image: image.png] Now, I can access https://192.168.3.84:4200 is OK, and I can log in and manage it. But, when I access http://192.168.3.84:8023: [image: image.png] can not type anything into it. Look forward to hearing from you! Ankele -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 9088 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 7799 bytes Desc: not available URL: From laurentfdumont at gmail.com Thu Nov 12 15:01:38 2020 From: laurentfdumont at gmail.com (Laurent Dumont) Date: Thu, 12 Nov 2020 10:01:38 -0500 Subject: Queens steal time [nova] In-Reply-To: <91f41182-bf21-659e-5204-ccd83f535694@gmail.com> References: <91f41182-bf21-659e-5204-ccd83f535694@gmail.com> Message-ID: Hi, Technically, I think that you always run the chance of "steal" time if you don't pin CPUs. I'm not sure if Openstack is "smart" enough to allocate CPUs that are not mapped to anyone in sequence (and start to overcommit once it's necessary. You might have 42 out of 48 free CPUs but I don't think that means that Openstack will prevent two VM from getting the same CPU scheduled (without CPU pinning). On Thu, Nov 12, 2020 at 9:09 AM Budai Laszlo wrote: > Hello all, > > we are comparing the behavior of our queens openstack with kilo. In > queens we are observing an increase in the steal time reported in the guest > along with the increase of the load averages. All this is happening while > the host is not overloaded, and reports 80+ idle time > > Initially we have suspected that the overcommit might be the reason of the > steal, so we have migrated vms, and now there are 42 vCPUs used out of the > 48 pCPUs, but in the guest we still observe the steal time. > > with similar configuration in openstack kilo we see smaller load, and > almost no steal time at all. > > what could be the reason of this steal time when there is no CPU > overcommit? > > Thank you for any ideas. > > Kind regards, > Laszlo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephenfin at redhat.com Thu Nov 12 15:23:41 2020 From: stephenfin at redhat.com (Stephen Finucane) Date: Thu, 12 Nov 2020 15:23:41 +0000 Subject: [tc][all][qinling] Retiring the Qinling project In-Reply-To: <175b3963a49.115662abe16508.6386586116324619581@ghanshyammann.com> References: <175b3963a49.115662abe16508.6386586116324619581@ghanshyammann.com> Message-ID: <3dd69b5e9a3ac32c4f6f7bae633fa509a6230325.camel@redhat.com> On Tue, 2020-11-10 at 13:16 -0600, Ghanshyam Mann wrote: Hello Everyone, As you know, Qinling is a leaderless project for the Wallaby cycle, which means there is no PTL candidate to lead it in the Wallaby cycle. 'No PTL' and no liaisons for DPL model is one of the criteria which triggers TC to start checking the health, maintainers of the project for dropping the project from OpenStack Governance[1]. TC discussed the leaderless project in PTG[2] and checked if the project has maintainers and what activities are done in the Victoria development cycle. It seems no functional changes in Qinling repos except few gate fixes or community goal commits[3]. Based on all these checks and no maintainer for Qinling, TC decided to drop this project from OpenStack governance in the Wallaby cycle.  Ref: Mandatory Repository Retirement resolution [4] and the detailed process is in the project guide docs [5]. If your organization product/customer use/rely on this project then this is the right time to step forward to maintain it otherwise from the Wallaby cycle, Qinling will move out of OpenStack governance by keeping their repo under OpenStack namespace with an empty master branch with 'Not Maintained' message in README. If someone from old or new maintainers shows interest to continue its development then it can be re-added to OpenStack governance. With that thanks to Qinling contributors and PTLs (especially lxkong ) for maintaining this project. No comments on the actual retirement, but don't forget that someone from the Foundation will need to update the OpenStack Map available at https://www.openstack.org/openstack-map and included on https://www.openstack.org/software/. Stephen [1] https://governance.openstack.org/tc/reference/dropping-projects.html [2] https://etherpad.opendev.org/p/tc-wallaby-ptg [3] https://www.stackalytics.com/?release=victoria&module=qinling-group&metric=commits [4] https://governance.openstack.org/tc/resolutions/20190711-mandatory-repository-retirement.html [5] https://docs.openstack.org/project-team-guide/repository.html#retiring-a-repository -gmann From stephenfin at redhat.com Thu Nov 12 15:26:50 2020 From: stephenfin at redhat.com (Stephen Finucane) Date: Thu, 12 Nov 2020 15:26:50 +0000 Subject: [tc][all][searchlight ] Retiring the Searchlight project In-Reply-To: References: <175b3960913.120cf390316504.5945799248975474230@ghanshyammann.com> <297cf22b-2172-cb51-f282-4c0e674a9a07@debian.org> <175b44e80fd.f4c0ee8420790.4317890968302424842@ghanshyammann.com> <7e1e40f2-afeb-ebcb-6faa-b3b7534a8039@openstack.org> Message-ID: <34947f0729c38aaa4e1d3b1bc20e9153c6bececb.camel@redhat.com> On Thu, 2020-11-12 at 21:42 +0900, Akihiro Motoki wrote: On Thu, Nov 12, 2020 at 7:31 PM Thierry Carrez wrote: > > Ghanshyam Mann wrote: > > Yes, as part of the retirement process all deliverables under the > > project needs to be removed > > and before removal we do: > > 1. Remove all dependencies. > > 2. Refactor/remove the gate job dependency also. > > 3. Remove the code from the retiring repo. > > I think Thomas's point was that some of those retired deliverables > are > required by non-retired deliverables, like: > > - python-qinlingclient being required by mistral-extra > > - python-searchlightclient and python-karborclient being required by > openstackclient and python-openstackclient > > We might need to remove those features/dependencies first, which > might > take time... Yeah, I think so too. Regarding OSC, python-openstackclient does not depend on python-searchlightclient. "openstackclient" is a wrapper project which allows us to install all OSC plugins along with the main OSC. We can drop retired OSC plugins from the "openstackclient" requirements. We only depend on them for documentation purposes. We'll just remove those docs. Stephen From juliaashleykreger at gmail.com Thu Nov 12 15:38:34 2020 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Thu, 12 Nov 2020 07:38:34 -0800 Subject: [tc][all] openstack.org website Was: [qinling] Retiring the Qinling project In-Reply-To: <3dd69b5e9a3ac32c4f6f7bae633fa509a6230325.camel@redhat.com> References: <175b3963a49.115662abe16508.6386586116324619581@ghanshyammann.com> <3dd69b5e9a3ac32c4f6f7bae633fa509a6230325.camel@redhat.com> Message-ID: Out of curiosity, and surely someone from the foundation will need to answer this question, but is there any plan to begin to migrate the openstack.org website to more community control or edit community capability since it has already been updated to be much more about the project and not the foundation? For example, for ironicbaremetal.org, we're able to go update content by updating one of the template files the site is built with, in order to fix links, update the latest version, etc. The openstack.org site is far more complex though so maybe it is not really feasible in the short term. Anyway, just a thought. Julia On Thu, Nov 12, 2020 at 7:26 AM Stephen Finucane wrote: > [trim] > > No comments on the actual retirement, but don't forget that someone > from the Foundation will need to update the OpenStack Map available at > https://www.openstack.org/openstack-map and included on > https://www.openstack.org/software/. > > Stephen > [trim] From allison at openstack.org Thu Nov 12 15:50:04 2020 From: allison at openstack.org (Allison Price) Date: Thu, 12 Nov 2020 09:50:04 -0600 Subject: Victoria Release Community Meeting In-Reply-To: References: <1605050603.25113268@apps.rackspace.com> <4c09adb4-0f97-f256-9827-01781643a9c3@debian.org> Message-ID: <74913C4F-FD55-4B6A-A87E-694A3E48B103@openstack.org> Thank you all for the feedback as we continue to evolve the community meetings. As we plan the next community meeting, we will actively investigate using a Jitsi instance and communicate back on the ML about how that progress is going. Today’s meeting will be on Zoom (in about 10 minutes!), but like I mentioned earlier, the recordings will be available via the Project Navigator and YouTube for folks who would not like to login to the platform. I’ll start a new thread when we make progress towards the next community meeting. If there is any other feedback, please let me know. Allison Allison Price Open Infrastructure Foundation allison at openstack.org > On Nov 12, 2020, at 7:38 AM, Erno Kuvaja wrote: > > On Wed, Nov 11, 2020 at 11:19 AM Thomas Goirand > wrote: > On 11/11/20 12:23 AM, helena at openstack.org wrote: > > The meeting will be held via Zoom. > > Could we *PLEASE* stop the Zoom non-sense? > > Zoom is: > - known to have a poor security record > - imposes the install of the desktop non-free app (yes I know, in some > cases, it is supposed to work without it, but so far it didn't work for me) > - controlled by a 3rd party we cannot trust > > It's not as if we had no alternatives. Jitsi works perfectly and was > used successfully for the whole of debconf, with voctomix and stuff, so > viewers can read a normal live video stream... > > If the foundation doesn't know how to do it, I can put people in touch > with the Debian video team. I'm sure they will be helpful. > > Cheers, > > Thomas Goirand (zigo) > > > Very much this, please. > > There are plenty of options out there and yet we _choose_ time after time to use the one that is not open source and has admitted neglecting their security and privacy issues; and effectively forces the usage of their application (I've yet to get into session without it like Thomas pointed out.) > > I know Zoom managed to put themselves on top of the hype wave when this COVID-19 mess started, but we should be able to do better than jumping on every single hype train out there. > > - Erno "jokke" Kuvaja -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Thu Nov 12 16:03:24 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 12 Nov 2020 16:03:24 +0000 Subject: Victoria Release Community Meeting In-Reply-To: References: <1605050603.25113268@apps.rackspace.com> <4c09adb4-0f97-f256-9827-01781643a9c3@debian.org> Message-ID: <20201112160324.xuo7zpumd47q6yx6@yuggoth.org> On 2020-11-12 13:38:11 +0000 (+0000), Erno Kuvaja wrote: [...] > effectively forces the usage of their application (I've yet to get > into session without it like Thomas pointed out.) [...] I'm no fan of Zoom either, for many of the aforementioned reasons, but here's how I've managed to get the Web-based client to work and not install their proprietary client/extension: 0. First, having a vanilla browser process seems to help, as I've seen privacy/security-oriented extensions and configuration options block the A/V stream connections. My normal locked-down browser is Firefox, so I have Chromium installed with no extensions and its default configuration which I run exclusively for accessing Zoom and similar videoconferencing sites. 1. Load the Zoom meeting URL and you will be prompted to "Open xdg-open" which you *don't* want (this is what will try to install the binary client). Instead click the "Cancel" button on that pop-up modal. 2. Now click on the "Launch Meeting" button on the page and the same xdg-open modal popup will appear again. "Cancel" it a second time. 3. Next you'll see that the page has suddenly added a small-print line which says "Having issues with Zoom Client? Join from Your Browser" so go ahead and click on the "Join from Your Browser" link. This is the "web client" Zoom would rather you didn't use (since I'm paranoid I assume it's because they prefer to have as much access to my system and my valuable data as possible). 4. Enter your name or nickname on the new page which loads. You'll probably also be presented with a "I'm not a robot" reCaptcha which you'll need to check and solve the subsequently presented puzzle to donate your mechanical turk time to train Google's AI algorithms to be able to recognize crosswalks, bicycles, chimneys, boats, traffic signals, palm trees, tractors, and other VERY IMPORTANT objects. 5. If you're good enough at solving puzzles, now you should be able to click the "Join" button on the page. 6. Enter the meeting passcode if prompted for one (likely buried somewhere in the invite). Simple, right? :/ -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From kaifeng.w at gmail.com Thu Nov 12 16:03:53 2020 From: kaifeng.w at gmail.com (Kaifeng Wang) Date: Fri, 13 Nov 2020 00:03:53 +0800 Subject: Ironic use shellinabox doesn't work In-Reply-To: References: Message-ID: Hi, "SOL Session operational" is a BMC prompt, actually you have successfully connected to it, before you can interact with the terminal, the Serial Redirection (or something called that) needs to be enabled in the BIOS, also make sure you have matching baud rate set to the bootloader for the tty. P.S. SOL does not work for Windows systems. On Thu, Nov 12, 2020 at 11:05 PM Ankele zhang wrote: > Hello~ > > I have a OpenStack platform( Rocky ) on CentOS7.6, and I installed > Ironic components on it. I can manage bare metal node with Ironic and I > plan to use shellinabox to manage the bare metal node remotely. > I had config conductor ironic.conf: > [DEFAULT] > ... > enabled_console_interfaces = ipmitool-shellinabox,no-console > I had config shellinabox: > USER=shellinabox > GROUP=shellinabox > CERTDIR=/var/lib/shellinabox > PORT=4200 > OPTS="--disable-ssl-menu -s /:LOGIN" > My 'openstack baremetal node console show BM01': > console_enabled: True and console_info.url: http://192.168.3.84:8023 > [image: image.png] > Now, I can access https://192.168.3.84:4200 is OK, and I can log in > and manage it. > But, when I access http://192.168.3.84:8023: > [image: image.png] > can not type anything into it. > > Look forward to hearing from you! > > > Ankele > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 9088 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 7799 bytes Desc: not available URL: From kennelson11 at gmail.com Thu Nov 12 16:04:54 2020 From: kennelson11 at gmail.com (Kendall Nelson) Date: Thu, 12 Nov 2020 08:04:54 -0800 Subject: Victoria Release Community Meeting In-Reply-To: <1605050603.25113268@apps.rackspace.com> References: <1605050603.25113268@apps.rackspace.com> Message-ID: Starting now! See you all there :) -Kendall Nelson (diablo_rojo) On Tue, Nov 10, 2020 at 3:24 PM helena at openstack.org wrote: > Hello, > > > > The community meeting for the Victoria release will be this Thursday, > November 12th at 16:00 UTC. The meeting will be held via Zoom. We will > show pre-recorded videos from our PTLs followed by live Q&A sessions. We > will have updates from Masakari, Telemetry, Neutron, and Cinder. > > > > Zoom Info: > https://zoom.us/j/2146866821?pwd=aDlpOXd5MXB3cExZWHlROEJURzh0QT09 > Meeting ID: 214 686 6821 > Passcode: Victoria > > Find your local number: https://zoom.us/u/8BRrV > > > > *Reminder to PTLs:* > > > > We would love for you to participate and give an update on your project. > > > > I have attached a template for the slides that you may use if you wish. The > video should be around 10 minutes. Please send in your video and slide for > the community meeting ASAP. I have only received content for the listed > above projects. If you are unable to make the meeting at the designated > time we can show your video and forward any questions for you. > > > > Let me know if you have any other questions! > > > > Thank you for your participation, > > Helena > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Thu Nov 12 16:26:58 2020 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Thu, 12 Nov 2020 10:26:58 -0600 Subject: [tc][all][qinling] Retiring the Qinling project In-Reply-To: <3dd69b5e9a3ac32c4f6f7bae633fa509a6230325.camel@redhat.com> References: <175b3963a49.115662abe16508.6386586116324619581@ghanshyammann.com> <3dd69b5e9a3ac32c4f6f7bae633fa509a6230325.camel@redhat.com> Message-ID: <175bd48122d.ee0d0ddb120064.3093467998927637704@ghanshyammann.com> ---- On Thu, 12 Nov 2020 09:23:41 -0600 Stephen Finucane wrote ---- > On Tue, 2020-11-10 at 13:16 -0600, Ghanshyam Mann wrote: > Hello Everyone, > > As you know, Qinling is a leaderless project for the Wallaby cycle, > which means there is no PTL > candidate to lead it in the Wallaby cycle. 'No PTL' and no liaisons for > DPL model is one of the criteria > which triggers TC to start checking the health, maintainers of the > project for dropping the project > from OpenStack Governance[1]. > > TC discussed the leaderless project in PTG[2] and checked if the > project has maintainers and what > activities are done in the Victoria development cycle. It seems no > functional changes in Qinling repos > except few gate fixes or community goal commits[3]. > > Based on all these checks and no maintainer for Qinling, TC decided to > drop this project from OpenStack > governance in the Wallaby cycle. Ref: Mandatory Repository Retirement > resolution [4] and the detailed process > is in the project guide docs [5]. > > If your organization product/customer use/rely on this project then > this is the right time to step forward to > maintain it otherwise from the Wallaby cycle, Qinling will move out of > OpenStack governance by keeping > their repo under OpenStack namespace with an empty master branch with > 'Not Maintained' message in README. > If someone from old or new maintainers shows interest to continue its > development then it can be re-added > to OpenStack governance. > > With that thanks to Qinling contributors and PTLs (especially lxkong ) > for maintaining this project. > > No comments on the actual retirement, but don't forget that someone > from the Foundation will need to update the OpenStack Map available at > https://www.openstack.org/openstack-map and included on > https://www.openstack.org/software/. Yes, that is part of removing the dependencies/usage of the retiring projects step. -gmann > > Stephen > > [1] > https://governance.openstack.org/tc/reference/dropping-projects.html > [2] https://etherpad.opendev.org/p/tc-wallaby-ptg > [3] > https://www.stackalytics.com/?release=victoria&module=qinling-group&metric=commits > [4] > https://governance.openstack.org/tc/resolutions/20190711-mandatory-repository-retirement.html > [5] > https://docs.openstack.org/project-team-guide/repository.html#retiring-a-repository > > -gmann > > > > > From gmann at ghanshyammann.com Thu Nov 12 16:30:21 2020 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Thu, 12 Nov 2020 10:30:21 -0600 Subject: [tc][all] openstack.org website Was: [qinling] Retiring the Qinling project In-Reply-To: References: <175b3963a49.115662abe16508.6386586116324619581@ghanshyammann.com> <3dd69b5e9a3ac32c4f6f7bae633fa509a6230325.camel@redhat.com> Message-ID: <175bd4b2c0d.126d14512120266.232243623967245442@ghanshyammann.com> ---- On Thu, 12 Nov 2020 09:38:34 -0600 Julia Kreger wrote ---- > Out of curiosity, and surely someone from the foundation will need to > answer this question, but is there any plan to begin to migrate the > openstack.org website to more community control or edit community > capability since it has already been updated to be much more about the > project and not the foundation? openstack-map repo is currently in OSF namespace but anyone can submit the changes and approval on changes is from Foundation. Example: Tricirlce retirement - https://review.opendev.org/#/c/735675/ -gmann > > For example, for ironicbaremetal.org, we're able to go update content > by updating one of the template files the site is built with, in order > to fix links, update the latest version, etc. The openstack.org site > is far more complex though so maybe it is not really feasible in the > short term. > > Anyway, just a thought. > > Julia > > On Thu, Nov 12, 2020 at 7:26 AM Stephen Finucane wrote: > > > [trim] > > > > No comments on the actual retirement, but don't forget that someone > > from the Foundation will need to update the OpenStack Map available at > > https://www.openstack.org/openstack-map and included on > > https://www.openstack.org/software/. > > > > Stephen > > > [trim] > > From owalsh at redhat.com Thu Nov 12 16:41:10 2020 From: owalsh at redhat.com (Oliver Walsh) Date: Thu, 12 Nov 2020 16:41:10 +0000 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: Message-ID: IIUC from Sean's reply most of the heavyweight configuration management frameworks already address the security concern. For tripleo the first issue to address is in puppet-nova where the dbs are currently configured for every nova service. The fix seems trivial - https://review.opendev.org/755689. I also think that should be completely safe to backport this to all stable branches. The tripleo changes in https://review.opendev.org/#/c/718552/ are not strictly necessary to remove the db creds from nova.conf. However I need to go further, also removing the hieradata that contains the db creds since completely removing the db creds from the compute hosts is the ultimate goal here. So when the configuration management frameworks are all good then what are we actually concerned about security-wise? Is it just operators that roll their own deployments? Cheers, Ollie On Wed, 11 Nov 2020 at 16:37, Balázs Gibizer wrote: > Dear packagers and deployment engine developers, > > Since Icehouse nova-compute service does not need any database > configuration as it uses the message bus to access data in the database > via the conductor service. Also, the nova configuration guide states > that the nova-compute service should not have the > [api_database]connection config set. Having any DB credentials > configured for the nova-compute is a security risk as well since that > service runs close to the hypervisor. Since Rocky[1] nova-compute > service fails if you configure API DB credentials and set upgrade_level > config to 'auto'. > > Now we are proposing a patch[2] that makes nova-compute fail at startup > if the [database]connection or the [api_database]connection is > configured. We know that this breaks at least the rpm packaging, debian > packaging, and puppet-nova. The problem there is that in an all-in-on > deployment scenario the nova.conf file generated by these tools is > shared between all the nova services and therefore nova-compute sees DB > credentials. As a counter-example, devstack generates a separate > nova-cpu.conf and passes that to the nova-compute service even in an > all-in-on setup. > > The nova team would like to merge [2] during Wallaby but we are OK to > delay the patch until Wallaby Milestone 2 so that the packagers and > deployment tools can catch up. Please let us know if you are impacted > and provide a way to track when you are ready with the modification > that allows [2] to be merged. > > There was a long discussion on #openstack-nova today[3] around this > topic. So you can find more detailed reasoning there[3]. > > Cheers, > gibi > > [1] > > https://github.com/openstack/nova/blob/dc93e3b510f53d5b2198c8edd22528f0c899617e/nova/compute/rpcapi.py#L441-L457 > [2] https://review.opendev.org/#/c/762176 > [3] > > http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2020-11-11.log.html#t2020-11-11T10:51:23 > -- > > http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2020-11-11.log.html#t2020-11-11T14:40:51 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zigo at debian.org Thu Nov 12 16:43:57 2020 From: zigo at debian.org (Thomas Goirand) Date: Thu, 12 Nov 2020 17:43:57 +0100 Subject: [tc][all][searchlight ] Retiring the Searchlight project In-Reply-To: <7e1e40f2-afeb-ebcb-6faa-b3b7534a8039@openstack.org> References: <175b3960913.120cf390316504.5945799248975474230@ghanshyammann.com> <297cf22b-2172-cb51-f282-4c0e674a9a07@debian.org> <175b44e80fd.f4c0ee8420790.4317890968302424842@ghanshyammann.com> <7e1e40f2-afeb-ebcb-6faa-b3b7534a8039@openstack.org> Message-ID: <8554915e-0ee1-7d69-1192-1a043b71f742@debian.org> On 11/12/20 11:29 AM, Thierry Carrez wrote: > Ghanshyam Mann wrote: >> Yes, as part of the retirement process all deliverables under the >> project needs to be removed >> and before removal we do: >> 1. Remove all dependencies. >> 2. Refactor/remove the gate job dependency also. >> 3. Remove the code from the retiring repo. > > I think Thomas's point was that some of those retired deliverables are > required by non-retired deliverables, like: > > - python-qinlingclient being required by mistral-extra > > - python-searchlightclient and python-karborclient being required by > openstackclient and python-openstackclient > > We might need to remove those features/dependencies first, which might > take time... Exactly, thanks for correcting my (very) poor wording. Cheers, Thomas Goirand (zigo) From thierry at openstack.org Thu Nov 12 16:48:25 2020 From: thierry at openstack.org (Thierry Carrez) Date: Thu, 12 Nov 2020 17:48:25 +0100 Subject: [tc][all] openstack.org website Was: [qinling] Retiring the Qinling project In-Reply-To: References: <175b3963a49.115662abe16508.6386586116324619581@ghanshyammann.com> <3dd69b5e9a3ac32c4f6f7bae633fa509a6230325.camel@redhat.com> Message-ID: <698503c9-1455-771b-6f9f-bdcd036b368d@openstack.org> Julia Kreger wrote: > Out of curiosity, and surely someone from the foundation will need to > answer this question, but is there any plan to begin to migrate the > openstack.org website to more community control or edit community > capability since it has already been updated to be much more about the > project and not the foundation? > > For example, for ironicbaremetal.org, we're able to go update content > by updating one of the template files the site is built with, in order > to fix links, update the latest version, etc. The openstack.org site > is far more complex though so maybe it is not really feasible in the > short term. That's definitely the general direction we want to take with openstack.org, but it will take a lot of time to separate out the various backends involved. Regarding the map, as Ghanshyam says, the requirements are driven from the osf/openstack-map repository so please submit any change there. I'll take the opportunity to remind people that the YAML data in that repository also directly drives the content for the openstack.org/software pages. So if you want to modify how each project appears there, that's already doable. -- Thierry From laszlo.budai at gmail.com Thu Nov 12 17:35:56 2020 From: laszlo.budai at gmail.com (Budai Laszlo) Date: Thu, 12 Nov 2020 19:35:56 +0200 Subject: Queens steal time [nova] In-Reply-To: References: <91f41182-bf21-659e-5204-ccd83f535694@gmail.com> Message-ID: <7ab6b03f-edf1-5fb2-0887-a2c3cc47f1b6@gmail.com> Hi Laurent, Thank you for your answer. I agree with you that without the pinning the steal time can appear anytime. What is strange to me that in openstack Kilo the steal is significantly smaller even when there is some overcommit. So I am wondering where to look for the difference? Kind regards, Laszlo On 11/12/20 5:01 PM, Laurent Dumont wrote: > Hi, > > Technically, I think that you always run the chance of "steal" time if you don't pin CPUs. I'm not sure if Openstack is "smart" enough to allocate CPUs that are not mapped to anyone in sequence (and start to overcommit once it's necessary. You might have 42 out of 48 free CPUs but I don't think that means that Openstack will prevent two VM from getting the same CPU scheduled (without CPU pinning). > > On Thu, Nov 12, 2020 at 9:09 AM Budai Laszlo > wrote: > > Hello all, > > we are comparing the behavior of our queens  openstack with kilo. In queens we are observing an increase in the steal time reported in the guest along with the increase of the load averages. All this is happening while the host is not overloaded, and reports 80+ idle time > > Initially we have suspected that the overcommit might be the reason of the steal, so we have migrated vms, and now there are 42 vCPUs used out of the 48 pCPUs, but in the guest we still observe the steal time. > > with similar configuration in openstack kilo we see smaller load, and almost no steal time at all. > > what could be the reason of this steal time when there is no CPU overcommit? > > Thank you for any ideas. > > Kind regards, > Laszlo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephenfin at redhat.com Thu Nov 12 19:03:37 2020 From: stephenfin at redhat.com (Stephen Finucane) Date: Thu, 12 Nov 2020 19:03:37 +0000 Subject: [nova] How best to provide virtio-based input devices? Message-ID: Design discussion for interested parties. As discussed during the nova team meeting today, we're looking at providing support for virtio-based input devices in nova, given benefits w.r.t. performance and security (no emulated USB bus!). The current proposal I have for this is to introduce a new image metadata property, 'hw_input_bus', and extend the existing 'hw_pointer_model' image metadata property, which currently only accepts a 'usbtablet' value, to accept 'mouse' or 'tablet' values. This means you'd end up with a matrix something like so: +------------------+--------------+------------------------+ | hw_pointer_model | hw_input_bus | Result | +------------------|--------------+------------------------+ | - | - | PS2-based mouse [*] | | usbtablet | - | USB-based tablet | | usbtablet | usb | USB-based tablet | | usbtablet | virtio | **ERROR** | | mouse | - | USB-based mouse | | mouse | usb | USB-based mouse | | mouse | virtio | virtio-based mouse | | tablet | - | USB-based tablet | | tablet | usb | USB-based tablet | | tablet | virtio | virtio-based tablet | +------------------+--------------+------------------------+ [*] libvirt adds these by default on x86 hosts dansmith noted that the only reason to select the 'mouse' pointer model nowadays is for compatibility, and something like a virtio-based mouse didn't really make sense. That being the case, I agree that this change is likely more complex that it needs to be. We do, however, disagree on the remedy. dansmith's idea is to drop the 'hw_input_bus' image metadata property entirely and simply add a new 'virtiotablet' value to 'hw_pointer_model' instead. This still leaves the question of what bus we should use for keyboards, and his suggestion there is to extrapolate out and use virtio for keyboards if 'hw_pointer_model=virtiotablet' is specified and presumably USB if 'hw_pointer_model=usbtablet'. Needless to say, I don't like this idea and prefer we took another tack and kept 'hw_input_bus' but didn't build on 'hw_pointer_model' and instead "deprecated" it. We can't really ever remove the an image metadata property, since that would be a breaking upgrade, which means we'll eventually be left with effectively dead code to maintain forever. However, I don't think that's a big deal. 'hw_pointer_model=usbtablet' is already on a path to obsolescence as the Q35 machine type slowly becomes the default on x86 hosts and the use of non-x86 hosts grows since neither support PS2 and must use a USB-based input device. In addition, I think the extrapolation of 'virtiotablet' to mean also virtio-based keyboard is unclear and leaves a gaping hole w.r.t. requesting USB-based keyboards on non-AArch64 hosts (where it's currently added by default), since we don't currently do this extrapolation and introducing it would be breaking change on x86 hosts (instances would suddenly switch from PS2-based keyboards to USB-based ones). We need to decide what approach to go for before I rework this. If anyone has input, particularly operators that think they'd use this feature, I'd love to hear it so that I can t̶e̶l̶l̶ ̶d̶a̶n̶s̶m̶i̶t̶h̶ ̶t̶o̶ ̶s̶h̶o̶v̶e̶ ̶i̶t̶ come to the best possible solution ;-) Feel free to either reply here or on the review [1]. Cheers, Stephen [1] https://review.opendev.org/#/c/756552/ From laurentfdumont at gmail.com Thu Nov 12 19:10:30 2020 From: laurentfdumont at gmail.com (Laurent Dumont) Date: Thu, 12 Nov 2020 14:10:30 -0500 Subject: Queens steal time [nova] In-Reply-To: <7ab6b03f-edf1-5fb2-0887-a2c3cc47f1b6@gmail.com> References: <91f41182-bf21-659e-5204-ccd83f535694@gmail.com> <7ab6b03f-edf1-5fb2-0887-a2c3cc47f1b6@gmail.com> Message-ID: Is the vCPU placement the same between the two? (if you do a virsh dumpxml of all the VMs on the compute, you should be able to see the which vCPU we're mapped to which VM CPU). The same VMs under a Kilo compute are seeing different Steal % when the compute is upgraded to Queens? I guess that overall % Steal will also be impacted by how busy and noisy the VMs are. My knowledge is far from exhaustive but I would be surprised at a loss of CPU performance between Kilo and Queens. On Thu, Nov 12, 2020 at 12:35 PM Budai Laszlo wrote: > Hi Laurent, > > Thank you for your answer. > I agree with you that without the pinning the steal time can appear > anytime. What is strange to me that in openstack Kilo the steal is > significantly smaller even when there is some overcommit. So I am wondering > where to look for the difference? > > Kind regards, > Laszlo > > On 11/12/20 5:01 PM, Laurent Dumont wrote: > > Hi, > > Technically, I think that you always run the chance of "steal" time if you > don't pin CPUs. I'm not sure if Openstack is "smart" enough to allocate > CPUs that are not mapped to anyone in sequence (and start to overcommit > once it's necessary. You might have 42 out of 48 free CPUs but I don't > think that means that Openstack will prevent two VM from getting the same > CPU scheduled (without CPU pinning). > > On Thu, Nov 12, 2020 at 9:09 AM Budai Laszlo > wrote: > >> Hello all, >> >> we are comparing the behavior of our queens openstack with kilo. In >> queens we are observing an increase in the steal time reported in the guest >> along with the increase of the load averages. All this is happening while >> the host is not overloaded, and reports 80+ idle time >> >> Initially we have suspected that the overcommit might be the reason of >> the steal, so we have migrated vms, and now there are 42 vCPUs used out of >> the 48 pCPUs, but in the guest we still observe the steal time. >> >> with similar configuration in openstack kilo we see smaller load, and >> almost no steal time at all. >> >> what could be the reason of this steal time when there is no CPU >> overcommit? >> >> Thank you for any ideas. >> >> Kind regards, >> Laszlo >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gouthampravi at gmail.com Thu Nov 12 19:26:57 2020 From: gouthampravi at gmail.com (Goutham Pacha Ravi) Date: Thu, 12 Nov 2020 11:26:57 -0800 Subject: [manila] IRC meetings canceled on Nov 19th and Nov 26th Message-ID: Hello Zorillas, As Vida Haririan informed us [1], we'll be hosting a bug triage call on Meetpad [2] instead of our weekly IRC meeting on 19th November 2020. We hope that you will all join us and squash one or more bugs on 19th! 26th November 2020 is a holiday in the US; and a bulk of the regular attendees will be off their computers. We discussed this in the meeting today, and decided to cancel this IRC meeting. Please share any concerns to #openstack-manila or here on this mailing list. Thanks, Goutham Pacha Ravi [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018629.html [2] https://meetpad.opendev.org/ManilaW-ReleaseBugSquash From fsbiz at yahoo.com Thu Nov 12 19:44:11 2020 From: fsbiz at yahoo.com (fsbiz at yahoo.com) Date: Thu, 12 Nov 2020 19:44:11 +0000 (UTC) Subject: [swift]: issues with multi region (swift as backend for glance) In-Reply-To: References: <46812675.2700917.1604706323822.ref@mail.yahoo.com> <46812675.2700917.1604706323822@mail.yahoo.com> Message-ID: <1048219189.4807712.1605210251139@mail.yahoo.com> Hi Erno, Thanks for your response. Just to clarify, each region (RegionOne and RegionTwo) has its own database.Keystone DB is shared between the two regions. Glance should be getting the following two endpoints (and it does). root at stg-cl1-dev-001:/opt/netbox# openstack endpoint list | grep swift | grep public | 38f4a2201b1e498c886051df85661c74 | RegionOne    | swift        | object-store | True    | public    | https://RegionOne.abc.com:7480/swift/v1              || 3ae563eb03f5479e9488f955400a514c | RegionTwo  | swift        | object-store | True    | public    | https://RegionTwo.abc.com:7480/swift/v1    | Here's the relevant config for glance with swift backend. [glance_store] stores = swiftdefault_store = swiftswift_store_auth_version = 3swift_store_auth_address = swift_store_user = service:glanceswift_store_key = swift_store_container = glanceswift_store_region = RegionTwo Since the configs support it, I assumed that when glance gets the endpoints from auth, it would match the region (RegionTwo) to get the correct endpoint and then send the swift request to https://RegionTwo.abc.com:7480/swift/v1 By default, the swift_store_endpoint is not set since it is taken from auth. If I force it to RegionTwo, things work well. swift_store_endpoint =  https://RegionTwo.abc.com/swift/v1 For some reason, glance_store is not matching the region to multiple endpoints coming in from auth. So it seems. Regards,Fred. On Thursday, November 12, 2020, 04:28:47 AM PST, Erno Kuvaja wrote: On Fri, Nov 6, 2020 at 11:49 PM fsbiz at yahoo.com wrote: Hi folks, We're on queens release.  We have just setup a 2nd region.  So, now we have two regions regionOne and regionTwo We had a storage cluster in regionOne. Everything works good.We also added another storage cluster in regionTwo and have created swift endpoints for this.Using swift API, everything works fine.  The container is properly created in regionOne or regionTwo asdesired. We are also using swift as the glance backend.  We are seeing an issue with this for regionTwo.When I create an image in regionTwo, it seems like the glance storage backend is not properly recognizingthe endpoint and wants to store the image in regionOne. This looks like a definite bug.I can work around it by overriding the endpoint using swift_store_endpoint but if there is a known bugabout this issue I would rather patch it than resort to overriding the URL endpoint returned from "auth". Is this a known bug ?  Again, we are on the latest Queens release. thanks,Fred. Hi Fred, With these details I'm not exactly sure what the bug would be here. Glance has no concept for availability zones or regions per se. It expects consistent database across the deployment and multi-store not being a thing in Queens yet, there really is no meaningful way to configure multiple instances of the same store type. While there is no enforcement of homogenous configuration across the Glance nodes, the storage side really depends on it for the service to operate correctly. Forcing Glance to use different stores with the same database will likely cause lots of confusion and poor user experience. I'd assume that to achieve what you are looking for you'd either need to upgrade your openstack deployment to recent version to take advantage of the multi-store work or use separate Glance deployments per region. best,Erno "jokke" Kuvaja -------------- next part -------------- An HTML attachment was scrubbed... URL: From dms at danplanet.com Thu Nov 12 19:50:46 2020 From: dms at danplanet.com (Dan Smith) Date: Thu, 12 Nov 2020 11:50:46 -0800 Subject: [nova] How best to provide virtio-based input devices? In-Reply-To: (Stephen Finucane's message of "Thu, 12 Nov 2020 19:03:37 +0000") References: Message-ID: > Design discussion for interested parties. As discussed during the nova > team meeting today, we're looking at providing support for virtio-based > input devices in nova, given benefits w.r.t. performance and security > (no emulated USB bus!). The current proposal I have for this is to > introduce a new image metadata property, 'hw_input_bus', and extend the > existing 'hw_pointer_model' image metadata property, which currently > only accepts a 'usbtablet' value, to accept 'mouse' or 'tablet' values. > This means you'd end up with a matrix something like so: > > +------------------+--------------+------------------------+ > | hw_pointer_model | hw_input_bus | Result | > +------------------|--------------+------------------------+ > | - | - | PS2-based mouse [*] | > | usbtablet | - | USB-based tablet | > | usbtablet | usb | USB-based tablet | > | usbtablet | virtio | **ERROR** | > | mouse | - | USB-based mouse | > | mouse | usb | USB-based mouse | > | mouse | virtio | virtio-based mouse | > | tablet | - | USB-based tablet | > | tablet | usb | USB-based tablet | > | tablet | virtio | virtio-based tablet | > +------------------+--------------+------------------------+ Yeah, my complaint here is that there are too many ways to describe things that can't possibly work, in addition to the things you might ask for that aren't supported by your virt driver (which are unavoidable). > dansmith noted that the only reason to select the 'mouse' pointer model > nowadays is for compatibility, and something like a virtio-based mouse > didn't really make sense. That being the case, I agree that this change > is likely more complex that it needs to be. We do, however, disagree on > the remedy. dansmith's idea is to drop the 'hw_input_bus' image > metadata property entirely and simply add a new 'virtiotablet' value to > 'hw_pointer_model' instead. Just for clarification, I want to drop the _new_ parameter from the _proposal_, as in not add it in the first place. > This still leaves the question of what bus we should use for > keyboards, and his suggestion there is to extrapolate out and use > virtio for keyboards if 'hw_pointer_model=virtiotablet' is specified > and presumably USB if 'hw_pointer_model=usbtablet'. Indeed. That leaves you with no new image metadata keys, no new object structural changes, deprecation implications thereof, and just a single new value for the existing key of "virtiotablet" (or even just "virtio"). I don't really care whether or not we change the usb case from how it works today. I think most people that care a lot about how the graphical console works are probably looking for pointer support more than anything else. > Needless to say, I don't like this idea and prefer we took another tack > and kept 'hw_input_bus' but didn't build on 'hw_pointer_model' and > instead "deprecated" it. We can't really ever remove the an image > metadata property, since that would be a breaking upgrade, which means > we'll eventually be left with effectively dead code to maintain > forever. However, I don't think that's a big deal. Right, so this is what I don't like. Users will come along trying to figure out how to get either a USB tablet or a virtio pointer, and be presented with a bunch of options. For years, google will return them results that point to the existing key that omit the new option. If they google for updated docs for that key, they won't find a new virtio-based value that they can use, but will hopefully find the explanation and truth table of how to get what they want, depending on how new or old their cloud is, what virt driver it's running, how new that virt driver is, and what platform they're using. And of course, we have to decide what to do if they specify both keys if they're confused by the forumla for deciding which to use. I'd much prefer to retain compatibility with images from the last ten years (or however long we've allowed this to be specified) and just add another value for the new model. Obviously "hw_pointer_model" isn't the nicest name, given that we're using it to determine both input devices, but I don't think that wrecking google results, docs, and people's images is really worth it. It's important to consider that people do have images and code that work on multiple clouds running various versions. It seems a lot nicer to me to just keep using the key that works everywhere, extended for the new value where available. --Dan From michaelr at catalyst.net.nz Thu Nov 12 20:39:35 2020 From: michaelr at catalyst.net.nz (Michael Richardson) Date: Fri, 13 Nov 2020 09:39:35 +1300 Subject: [neutron] BaGPipe experiences Message-ID: Hi all, Is anyone using the BaGPipe driver[0] in production? Any comments, experiences, config. recommendations, war stories, tales of caution you would like to share? Cheers, Michael [0] https://docs.openstack.org/networking-bagpipe/latest/ -- Michael Richardson Catalyst Cloud || Catalyst IT Limited https://catalystcloud.nz/ GPG: 0530 4686 F996 4E2C 5DC7 6327 5C98 5EED A30 From skaplons at redhat.com Thu Nov 12 21:09:14 2020 From: skaplons at redhat.com (Slawek Kaplonski) Date: Thu, 12 Nov 2020 22:09:14 +0100 Subject: [neutron] Drivers meeting agenda Message-ID: <7318574.0nDEsV06r8@p1> Hi, For tomorrow's drivers meeting we have one item in the "On Demand" section. It's added by Oleg and is related to the bug https://bugs.launchpad.net/ neutron/+bug/1887523/ So lets meet tomorrow and discuss about that. See You on the meeting :) -- Slawek Kaplonski Principal Software Engineer Red Hat From kennelson11 at gmail.com Thu Nov 12 22:29:49 2020 From: kennelson11 at gmail.com (Kendall Nelson) Date: Thu, 12 Nov 2020 14:29:49 -0800 Subject: [SDK][OSC] Meeting Times In-Reply-To: References: Message-ID: Sorry I am so slow at replying here! 14:00 UTC works for me so long as its only once a month I need to wake up at 6AM lol. I proposed the patch here: https://review.opendev.org/762590 -Kendall (diablo_rojo) On Thu, Oct 29, 2020 at 1:25 AM Artem Goncharov wrote: > Thanks Kendall for starting the discussion. > > Being located in CET (UTC+1/2) I am fine going one hour earlier (14:00 > UTC) to have it not so late for Akihiro and avoid clash with Manila, but am > also flexible making it 16:00 (cancelled API-SIG). > > Maybe a doodle will help to pick the most suitable? I hope to get a bit > more answers from other interested parties. > > Regards, > Artem > > > On 29. Oct 2020, at 02:48, Akihiro Motoki wrote: > > > > Thanks for starting the thread. > > I agree it is a good idea to have a regular meeting even though it is > > less frequent. > > > > Thursday 15UTC is okay with me. > > 16UTC is a bit late to me as it is 1am in my local time. One hour > > earlier (14UTC) also works for me. > > > > Thanks, > > Akihiro Motoki (amotoki) > > > > On Thu, Oct 29, 2020 at 7:49 AM Kendall Nelson > wrote: > >> > >> Hello! > >> > >> In the PTG session today we talked about doing some sort of regular > meetings to kind of jump start things after the more recent lack of > activity. We discussed beginning with more frequent meetings (a couple > across the next few weeks) and then shifting to a more relaxed monthly > cadence. > >> > >> I propose 15:00 UTC on the third thursday of each month as our monthly > meeting time? If people agree, I will propose a patch :) > >> > >> As for the more frequent ones to keep the momentum from discussion from > this week/last week. We could use that time (15 UTC) and date (Thursdays) > and maybe just do them on Nov 12 and 19th to keep us moving? That gives us > next week to catch up/ take a breath from the last two weeks, but not > waiting till after the US Thanksgiving holiday. > >> > >> Let me know what you think! > >> > >> -Kendall Nelson (diablo_rojo) > >> > >> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennelson11 at gmail.com Thu Nov 12 22:31:25 2020 From: kennelson11 at gmail.com (Kendall Nelson) Date: Thu, 12 Nov 2020 14:31:25 -0800 Subject: [SDK][OSC] Meeting Times In-Reply-To: References: Message-ID: I also created this etherpad to hold our meeting agendas: https://etherpad.opendev.org/p/openstacksdk-meeting-agenda -Kendall (diablo_rojo) On Thu, Nov 12, 2020 at 2:29 PM Kendall Nelson wrote: > Sorry I am so slow at replying here! > > 14:00 UTC works for me so long as its only once a month I need to wake up > at 6AM lol. > > I proposed the patch here: https://review.opendev.org/762590 > > -Kendall (diablo_rojo) > > On Thu, Oct 29, 2020 at 1:25 AM Artem Goncharov > wrote: > >> Thanks Kendall for starting the discussion. >> >> Being located in CET (UTC+1/2) I am fine going one hour earlier (14:00 >> UTC) to have it not so late for Akihiro and avoid clash with Manila, but am >> also flexible making it 16:00 (cancelled API-SIG). >> >> Maybe a doodle will help to pick the most suitable? I hope to get a bit >> more answers from other interested parties. >> >> Regards, >> Artem >> >> > On 29. Oct 2020, at 02:48, Akihiro Motoki wrote: >> > >> > Thanks for starting the thread. >> > I agree it is a good idea to have a regular meeting even though it is >> > less frequent. >> > >> > Thursday 15UTC is okay with me. >> > 16UTC is a bit late to me as it is 1am in my local time. One hour >> > earlier (14UTC) also works for me. >> > >> > Thanks, >> > Akihiro Motoki (amotoki) >> > >> > On Thu, Oct 29, 2020 at 7:49 AM Kendall Nelson >> wrote: >> >> >> >> Hello! >> >> >> >> In the PTG session today we talked about doing some sort of regular >> meetings to kind of jump start things after the more recent lack of >> activity. We discussed beginning with more frequent meetings (a couple >> across the next few weeks) and then shifting to a more relaxed monthly >> cadence. >> >> >> >> I propose 15:00 UTC on the third thursday of each month as our monthly >> meeting time? If people agree, I will propose a patch :) >> >> >> >> As for the more frequent ones to keep the momentum from discussion >> from this week/last week. We could use that time (15 UTC) and date >> (Thursdays) and maybe just do them on Nov 12 and 19th to keep us moving? >> That gives us next week to catch up/ take a breath from the last two weeks, >> but not waiting till after the US Thanksgiving holiday. >> >> >> >> Let me know what you think! >> >> >> >> -Kendall Nelson (diablo_rojo) >> >> >> >> >> >> >> > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosmaita.fossdev at gmail.com Thu Nov 12 23:56:44 2020 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Thu, 12 Nov 2020 18:56:44 -0500 Subject: [cinder][ops] restricting the Ceph version used with Cinder Message-ID: The Cinder project plans to take advantage of recent developments in Ceph to make some improvements to the RBD driver. To do that, we propose restricting the Cinder-supported releases of Ceph to the active stable releases plus the two prior releases. This will make Mimic the minimum supported version of Ceph for the Wallaby and X releases of Cinder. This is explained in a bit more detail in a patch to the RBD driver documentation: https://review.opendev.org/#/c/762592/ If you have concerns about this proposal, please leave comments on the review. Thank you, brian From tobias.urdin at binero.com Fri Nov 13 00:59:32 2020 From: tobias.urdin at binero.com (Tobias Urdin) Date: Fri, 13 Nov 2020 00:59:32 +0000 Subject: [cinder][ops] restricting the Ceph version used with Cinder In-Reply-To: References: Message-ID: Hello Brian, Thanks for the information! Really appreciate that it’s communicated properly. I have a question, I think it’s a little harsh to constraint deployments needing the same release for server and client when The Ceph project itself guarantees backward compatibility. What is the reasoning behind this and will Cinder upstream ensure that upgrade paths between Ceph releases are not broken? Best regards > On 13 Nov 2020, at 01:00, Brian Rosmaita wrote: > > The Cinder project plans to take advantage of recent developments in Ceph to make some improvements to the RBD driver. To do that, we propose restricting the Cinder-supported releases of Ceph to the active stable releases plus the two prior releases. > > This will make Mimic the minimum supported version of Ceph for the Wallaby and X releases of Cinder. > > This is explained in a bit more detail in a patch to the RBD driver documentation: > https://review.opendev.org/#/c/762592/ > > If you have concerns about this proposal, please leave comments on the review. > > Thank you, > brian > From melwittt at gmail.com Fri Nov 13 01:09:40 2020 From: melwittt at gmail.com (melanie witt) Date: Thu, 12 Nov 2020 17:09:40 -0800 Subject: [nova] How best to provide virtio-based input devices? In-Reply-To: References: Message-ID: On 11/12/20 11:03, Stephen Finucane wrote: > Design discussion for interested parties. As discussed during the nova > team meeting today, we're looking at providing support for virtio-based > input devices in nova, given benefits w.r.t. performance and security > (no emulated USB bus!). The current proposal I have for this is to > introduce a new image metadata property, 'hw_input_bus', and extend the > existing 'hw_pointer_model' image metadata property, which currently > only accepts a 'usbtablet' value, to accept 'mouse' or 'tablet' values. > This means you'd end up with a matrix something like so: > > +------------------+--------------+------------------------+ > | hw_pointer_model | hw_input_bus | Result | > +------------------|--------------+------------------------+ > | - | - | PS2-based mouse [*] | > | usbtablet | - | USB-based tablet | > | usbtablet | usb | USB-based tablet | > | usbtablet | virtio | **ERROR** | > | mouse | - | USB-based mouse | > | mouse | usb | USB-based mouse | > | mouse | virtio | virtio-based mouse | > | tablet | - | USB-based tablet | > | tablet | usb | USB-based tablet | > | tablet | virtio | virtio-based tablet | > +------------------+--------------+------------------------+ > > [*] libvirt adds these by default on x86 hosts > > dansmith noted that the only reason to select the 'mouse' pointer model > nowadays is for compatibility, and something like a virtio-based mouse > didn't really make sense. That being the case, I agree that this change > is likely more complex that it needs to be. +1, agree that having several user choices for pointer + bus that result in invalid or nonsensical combinations would not be a positive UX. > We do, however, disagree on > the remedy. dansmith's idea is to drop the 'hw_input_bus' image > metadata property entirely and simply add a new 'virtiotablet' value to > 'hw_pointer_model' instead. This still leaves the question of what bus > we should use for keyboards, and his suggestion there is to extrapolate > out and use virtio for keyboards if 'hw_pointer_model=virtiotablet' is > specified and presumably USB if 'hw_pointer_model=usbtablet'. > > Needless to say, I don't like this idea and prefer we took another tack > and kept 'hw_input_bus' but didn't build on 'hw_pointer_model' and > instead "deprecated" it. We can't really ever remove the an image > metadata property, since that would be a breaking upgrade, which means > we'll eventually be left with effectively dead code to maintain > forever. However, I don't think that's a big deal. > 'hw_pointer_model=usbtablet' is already on a path to obsolescence as > the Q35 machine type slowly becomes the default on x86 hosts and the > use of non-x86 hosts grows since neither support PS2 and must use a > USB-based input device. In addition, I think the extrapolation of > 'virtiotablet' to mean also virtio-based keyboard is unclear and leaves > a gaping hole w.r.t. requesting USB-based keyboards on non-AArch64 > hosts (where it's currently added by default), since we don't currently > do this extrapolation and introducing it would be breaking change on > x86 hosts (instances would suddenly switch from PS2-based keyboards to > USB-based ones). If I understand correctly, we do choose the "best fit" keyboard based on architecture, independent of the requested hw_pointer_model, today. It feels like it would be simpler to continue doing that and add a virtio choice to hw_pointer_model and let the driver pick the "best" keyboard to go along with that. Is it your view that having the driver choose a virtio keyboard if hw_pointer_model=virtiotablet is inconsistent with the existing "best fit" keyboard selection behavior? From what I understand, the pointer is the only user selection we can guarantee and the keyboard is architecture dependent. If we "deprecated" hw_pointer_model and introduced hw_input_bus, how does the user know which thing (pointer or keyboard) they are specifying? If users can't actually choose the keyboard and can only choose the pointer, wouldn't presenting a selection of a generic "hw_input_bus" be more confusing than hw_pointer_model? Best, -melanie > We need to decide what approach to go for before I rework this. If > anyone has input, particularly operators that think they'd use this > feature, I'd love to hear it so that I can t̶e̶l̶l̶ ̶d̶a̶n̶s̶m̶i̶t̶h̶ > ̶t̶o̶ ̶s̶h̶o̶v̶e̶ ̶i̶t̶ come to the best possible solution ;-) Feel > free to either reply here or on the review [1]. > > Cheers, > Stephen > > [1] https://review.opendev.org/#/c/756552/ > > From tkajinam at redhat.com Fri Nov 13 01:25:01 2020 From: tkajinam at redhat.com (Takashi Kajinami) Date: Fri, 13 Nov 2020 10:25:01 +0900 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: Message-ID: > For tripleo the first issue to address is in puppet-nova where the dbs are currently configured for every nova service. > The fix seems trivial - https://review.opendev.org/755689. I also think that should be completely safe to backport this to all stable branches. I don't know whether we can backport that to stable branches. I agreed to remove nova::db from the base nova class because we already deprecated database parameters in the nova class, but in stable branches we have these parameters still valid and removal of nova::db can cause some issues with these parameters. (I guess pick dosn't work if the nova class was defined AFTER nova::db class and there are no hieradata used) So I'd say it's better to leave it in stable branches if nova doesn't require absence of db parameters in stable branches. Note that we can remove these parameters from compute nodes in TripleO deployment if we completely remove these hieradata from compute nodes. Also from puppet's perspective we still need some fixes because the standalone deployment can still be broken with the change in nova. We need to know what would be the decision made in each distro packaging and use the proper config files to store db parameters or the other parameters. On Fri, Nov 13, 2020 at 1:43 AM Oliver Walsh wrote: > IIUC from Sean's reply most of the heavyweight configuration management > frameworks already address the security concern. > > For tripleo the first issue to address is in puppet-nova where the dbs are > currently configured for every nova service. The fix seems trivial - > https://review.opendev.org/755689. I also think that should be > completely safe to backport this to all stable branches. > > The tripleo changes in https://review.opendev.org/#/c/718552/ are not > strictly necessary to remove the db creds from nova.conf. However I need > to go further, also removing the hieradata that contains the db creds since > completely removing the db creds from the compute hosts is the > ultimate goal here. > > So when the configuration management frameworks are all good then what are > we actually concerned about security-wise? Is it just operators that roll > their own deployments? > > Cheers, > Ollie > > On Wed, 11 Nov 2020 at 16:37, Balázs Gibizer > wrote: > >> Dear packagers and deployment engine developers, >> >> Since Icehouse nova-compute service does not need any database >> configuration as it uses the message bus to access data in the database >> via the conductor service. Also, the nova configuration guide states >> that the nova-compute service should not have the >> [api_database]connection config set. Having any DB credentials >> configured for the nova-compute is a security risk as well since that >> service runs close to the hypervisor. Since Rocky[1] nova-compute >> service fails if you configure API DB credentials and set upgrade_level >> config to 'auto'. >> >> Now we are proposing a patch[2] that makes nova-compute fail at startup >> if the [database]connection or the [api_database]connection is >> configured. We know that this breaks at least the rpm packaging, debian >> packaging, and puppet-nova. The problem there is that in an all-in-on >> deployment scenario the nova.conf file generated by these tools is >> shared between all the nova services and therefore nova-compute sees DB >> credentials. As a counter-example, devstack generates a separate >> nova-cpu.conf and passes that to the nova-compute service even in an >> all-in-on setup. >> >> The nova team would like to merge [2] during Wallaby but we are OK to >> delay the patch until Wallaby Milestone 2 so that the packagers and >> deployment tools can catch up. Please let us know if you are impacted >> and provide a way to track when you are ready with the modification >> that allows [2] to be merged. >> >> There was a long discussion on #openstack-nova today[3] around this >> topic. So you can find more detailed reasoning there[3]. >> >> Cheers, >> gibi >> >> [1] >> >> https://github.com/openstack/nova/blob/dc93e3b510f53d5b2198c8edd22528f0c899617e/nova/compute/rpcapi.py#L441-L457 >> [2] https://review.opendev.org/#/c/762176 >> [3] >> >> http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2020-11-11.log.html#t2020-11-11T10:51:23 >> -- >> >> http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2020-11-11.log.html#t2020-11-11T14:40:51 >> >> >> >> -- ---------- Takashi Kajinami Senior Software Maintenance Engineer Customer Experience and Engagement Red Hat e-mail: tkajinam at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbasaras at gmail.com Fri Nov 13 07:01:41 2020 From: pbasaras at gmail.com (Pavlos Basaras) Date: Fri, 13 Nov 2020 09:01:41 +0200 Subject: Cannot deploly an instance at a specific host --(no such host found) [nova] In-Reply-To: <20201112091619.Horde.16cjrNDJAI_5LCsfMauhMaK@webmail.nde.ag> References: <20201111132022.Horde.q9K8xVfq2klzzypYBltanTa@webmail.nde.ag> <20201111140328.Horde.e4UaBmIP6Q_GOnn4VutjAea@webmail.nde.ag> <20201112091619.Horde.16cjrNDJAI_5LCsfMauhMaK@webmail.nde.ag> Message-ID: Hello, thanks for your help. I only added one extra compute node, and i changed the nova.conf on this node to match the controller's. Here are the commands. $ nova-manage cell_v2 list_cells --verbose +-------+--------------------------------------+-----------------------------------------------------------+--------------------------------------------------------------+----------+ | Name | UUID | Transport URL | Database Connection | Disabled | +-------+--------------------------------------+-----------------------------------------------------------+--------------------------------------------------------------+----------+ | cell0 | 00000000-0000-0000-0000-000000000000 | none:/// | mysql+pymysql:// root:linux at 127.0.0.1/nova_cell0?charset=utf8 | False | | cell1 | 1522c22f-64d4-4882-8ae8-ed0f9407407c | rabbit:// stackrabbit:linux at 192.168.40.184:5672/nova_cell1 | mysql+pymysql:// root:linux at 127.0.0.1/nova_cell1?charset=utf8 | False | +-------+--------------------------------------+-----------------------------------------------------------+--------------------------------------------------------------+----------+ $ sudo rabbitmqctl list_vhosts Listing vhosts / nova_cell1 $ sudo rabbitmqctl list_permissions -p nova_cell1 Listing permissions in vhost "nova_cell1" stackrabbit .* .* .* best, P. On Thu, Nov 12, 2020 at 11:16 AM Eugen Block wrote: > Did you change the transport_url only in the nova.conf of the new > compute node? Or did you also change the rabbitmq configuration? The > transport_url should match the actual rabbitmq config, of course, and > it should be the same on every node. > Does that match your cell setup? To compare run: > > control:~ # nova-manage cell_v2 list_cells --verbose > > Do you have a vhost configuration? (I'm not familiar with devstack) > Here's an example of a "nova" vhost with respective permissions: > > > control:~ # rabbitmqctl list_vhosts > Listing vhosts > / > nova > > control:~ # rabbitmqctl list_permissions -p nova > Listing permissions in vhost "nova" > nova .* .* .* > > > If there's a vhost it should be also reflected in the transport_url. > Maybe you should share all of the above information here. > > > Zitat von Pavlos Basaras : > > > Hello, > > > > maybe there is stg wrong with the installation. > > > > Let me clarify a few things. > > > > I have devstack deployed in a VM (pre-installed: keystone, glance, nova, > > placement, cinder, neutron, and horizon.) > > I can deploy machines successfully at the devstack controller space > > --everything seems to work fine. --> is seems to work fine with > opensource > > mano as well > > > > I am trying to add another pc as a compute host to be able to deploy vms > at > > this new compute host following ( > > > https://docs.openstack.org/nova/queens/install/compute-install-ubuntu.html > ) > > > > Also attached the nova.conf file. The only major differences are: > > --the transport url for rabbitmq which i made according to the transport > > url of the controller, i.e., instead of > rabbit://openstack:linux at controller > > i have rabbit://stackrabbit:linux at controller > > -- i replaced the ports with the service, e.g., instead using the 5000 > port > > --> "http://controller/identity/v3" instead of " > http://controller:5000/v3" > > > > please excuse (any) newbie questions > > > > all the best, > > Pavlos. > > > > > > On Wed, Nov 11, 2020 at 4:03 PM Eugen Block wrote: > > > >> There might be some mixup during the setup, I'm not sure how the other > >> cell would be created. I'd probably delete the cell with UUID > >> 1a0fde85-8906-46fb-b721-01a28c978439 and retry the discover_hosts with > >> the right cell UUID: > >> > >> nova-manage cell_v2 delete_cell --cell_uuid > >> 1a0fde85-8906-46fb-b721-01a28c978439 > >> nova-manage cell_v2 discover_hosts --cell_uuid > >> 1522c22f-64d4-4882-8ae8-ed0f9407407c > >> > >> Does that work? > >> > >> > >> Zitat von Pavlos Basaras : > >> > >> > Hello, > >> > > >> > yes i have this discover_hosts_in_cells_interval = 300 > >> > > >> > > >> > interestingly when i issued a combination of map_cell_and_hosts and > >> > update_cell > >> > > >> > the output from: nova-manage cell_v2 list_hosts > >> > +-----------+--------------------------------------+-------------+ > >> > | Cell Name | Cell UUID | Hostname | > >> > +-----------+--------------------------------------+-------------+ > >> > | None | 1a0fde85-8906-46fb-b721-01a28c978439 | computenode | > >> > | None | 1a0fde85-8906-46fb-b721-01a28c978439 | nrUE | > >> > | cell1 | 1522c22f-64d4-4882-8ae8-ed0f9407407c | openstack | > >> > +-----------+--------------------------------------+-------------+ > >> > > >> > when the new compute nodes seem to not have a cell mapped > >> > > >> > best, > >> > P. > >> > > >> > > >> > On Wed, Nov 11, 2020 at 3:26 PM Eugen Block wrote: > >> > > >> >> Hm, > >> >> > >> >> indeed rather strange to me. > >> >> > >> >> Do you see anything in the nova-scheduler.log? If you activated the > >> >> > >> >> discover_hosts_in_cells_interval = 300 > >> >> > >> >> it should query for new hosts every 5 minutes. > >> >> > >> >> > >> >> > >> >> Zitat von Pavlos Basaras : > >> >> > >> >> > Hello, > >> >> > > >> >> > thanks very much for your prompt reply. > >> >> > > >> >> > > >> >> > regarding the first command "nova-manage cell_v2 list_hosts" the > >> output > >> >> is > >> >> > the following (openstack is the host of the controller). I dont see > >> any > >> >> > other node here, even when i execute the discover_hosts command > >> >> > > >> >> > +-----------+--------------------------------------+-----------+ > >> >> > | Cell Name | Cell UUID | Hostname | > >> >> > +-----------+--------------------------------------+-----------+ > >> >> > | cell1 | 1522c22f-64d4-4882-8ae8-ed0f9407407c | openstack | > >> >> > +-----------+--------------------------------------+-----------+ > >> >> > > >> >> > > >> >> > Also this is the output from my controller when i use the command: > >> sudo > >> >> -s > >> >> > /bin/sh -c "nova-manage cell_v2 discover_hosts --verbose" nova > (not > >> >> sure > >> >> > if this helps) > >> >> > Found 2 cell mappings. > >> >> > Skipping cell0 since it does not contain hosts. > >> >> > Getting computes from cell 'cell1': > >> 1522c22f-64d4-4882-8ae8-ed0f9407407c > >> >> > Found 0 unmapped computes in cell: > >> 1522c22f-64d4-4882-8ae8-ed0f9407407c > >> >> > > >> >> > any thoughts? > >> >> > > >> >> > > >> >> > best, > >> >> > Pavlos. > >> >> > >> >> > >> >> > >> >> > >> >> > >> > >> > >> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From katonalala at gmail.com Fri Nov 13 07:27:37 2020 From: katonalala at gmail.com (Lajos Katona) Date: Fri, 13 Nov 2020 08:27:37 +0100 Subject: [neutron] BaGPipe experiences In-Reply-To: References: Message-ID: Hi, We use only networking-bgpvpn and instead of bagpipe as backend use networking-odl. Regards Lajos (lajoskatona) Michael Richardson ezt írta (időpont: 2020. nov. 12., Cs, 21:41): > Hi all, > > Is anyone using the BaGPipe driver[0] in production? Any comments, > experiences, config. recommendations, war stories, tales of caution you > would like to share? > > Cheers, > > Michael > > [0] https://docs.openstack.org/networking-bagpipe/latest/ > > > -- > Michael Richardson > Catalyst Cloud || Catalyst IT Limited > https://catalystcloud.nz/ > GPG: 0530 4686 F996 4E2C 5DC7 6327 5C98 5EED A30 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eblock at nde.ag Fri Nov 13 08:17:21 2020 From: eblock at nde.ag (Eugen Block) Date: Fri, 13 Nov 2020 08:17:21 +0000 Subject: Cannot deploly an instance at a specific host --(no such host found) [nova] In-Reply-To: References: <20201111132022.Horde.q9K8xVfq2klzzypYBltanTa@webmail.nde.ag> <20201111140328.Horde.e4UaBmIP6Q_GOnn4VutjAea@webmail.nde.ag> <20201112091619.Horde.16cjrNDJAI_5LCsfMauhMaK@webmail.nde.ag> Message-ID: <20201113081721.Horde.5OvFmSM2N39iluHJRlPYy17@webmail.nde.ag> The database connection doesn't look right, the compute node also needs access to the nova database (localhost is not reachable for another compute node) and usually with the nova user, not root, but that might be a devstack thing, I can't tell. The db settings in your nova.conf also seem wrong: [database] connection = sqlite:////var/lib/nova/nova.sqlite This should point to the nova database on the control node matching the one from 'nova-manage cell_v2 list_cells' command. I think there are lots of things not matching a multi-node setup, you'll need to fix that. As I said, I'm not familiar with devstack at all so I can't really tell exactly what needs to be done. Regards, Eugen Zitat von Pavlos Basaras : > Hello, > > thanks for your help. > > I only added one extra compute node, and i changed the nova.conf on this > node to match the controller's. > > Here are the commands. > > $ nova-manage cell_v2 list_cells --verbose > +-------+--------------------------------------+-----------------------------------------------------------+--------------------------------------------------------------+----------+ > | Name | UUID | > Transport URL | Database > Connection | Disabled | > +-------+--------------------------------------+-----------------------------------------------------------+--------------------------------------------------------------+----------+ > | cell0 | 00000000-0000-0000-0000-000000000000 | > none:/// | mysql+pymysql:// > root:linux at 127.0.0.1/nova_cell0?charset=utf8 | False | > | cell1 | 1522c22f-64d4-4882-8ae8-ed0f9407407c | rabbit:// > stackrabbit:linux at 192.168.40.184:5672/nova_cell1 | mysql+pymysql:// > root:linux at 127.0.0.1/nova_cell1?charset=utf8 | False | > +-------+--------------------------------------+-----------------------------------------------------------+--------------------------------------------------------------+----------+ > > $ sudo rabbitmqctl list_vhosts > Listing vhosts > / > nova_cell1 > > > $ sudo rabbitmqctl list_permissions -p nova_cell1 > Listing permissions in vhost "nova_cell1" > stackrabbit .* .* .* > > > best, > P. > > > On Thu, Nov 12, 2020 at 11:16 AM Eugen Block wrote: > >> Did you change the transport_url only in the nova.conf of the new >> compute node? Or did you also change the rabbitmq configuration? The >> transport_url should match the actual rabbitmq config, of course, and >> it should be the same on every node. >> Does that match your cell setup? To compare run: >> >> control:~ # nova-manage cell_v2 list_cells --verbose >> >> Do you have a vhost configuration? (I'm not familiar with devstack) >> Here's an example of a "nova" vhost with respective permissions: >> >> >> control:~ # rabbitmqctl list_vhosts >> Listing vhosts >> / >> nova >> >> control:~ # rabbitmqctl list_permissions -p nova >> Listing permissions in vhost "nova" >> nova .* .* .* >> >> >> If there's a vhost it should be also reflected in the transport_url. >> Maybe you should share all of the above information here. >> >> >> Zitat von Pavlos Basaras : >> >> > Hello, >> > >> > maybe there is stg wrong with the installation. >> > >> > Let me clarify a few things. >> > >> > I have devstack deployed in a VM (pre-installed: keystone, glance, nova, >> > placement, cinder, neutron, and horizon.) >> > I can deploy machines successfully at the devstack controller space >> > --everything seems to work fine. --> is seems to work fine with >> opensource >> > mano as well >> > >> > I am trying to add another pc as a compute host to be able to deploy vms >> at >> > this new compute host following ( >> > >> https://docs.openstack.org/nova/queens/install/compute-install-ubuntu.html >> ) >> > >> > Also attached the nova.conf file. The only major differences are: >> > --the transport url for rabbitmq which i made according to the transport >> > url of the controller, i.e., instead of >> rabbit://openstack:linux at controller >> > i have rabbit://stackrabbit:linux at controller >> > -- i replaced the ports with the service, e.g., instead using the 5000 >> port >> > --> "http://controller/identity/v3" instead of " >> http://controller:5000/v3" >> > >> > please excuse (any) newbie questions >> > >> > all the best, >> > Pavlos. >> > >> > >> > On Wed, Nov 11, 2020 at 4:03 PM Eugen Block wrote: >> > >> >> There might be some mixup during the setup, I'm not sure how the other >> >> cell would be created. I'd probably delete the cell with UUID >> >> 1a0fde85-8906-46fb-b721-01a28c978439 and retry the discover_hosts with >> >> the right cell UUID: >> >> >> >> nova-manage cell_v2 delete_cell --cell_uuid >> >> 1a0fde85-8906-46fb-b721-01a28c978439 >> >> nova-manage cell_v2 discover_hosts --cell_uuid >> >> 1522c22f-64d4-4882-8ae8-ed0f9407407c >> >> >> >> Does that work? >> >> >> >> >> >> Zitat von Pavlos Basaras : >> >> >> >> > Hello, >> >> > >> >> > yes i have this discover_hosts_in_cells_interval = 300 >> >> > >> >> > >> >> > interestingly when i issued a combination of map_cell_and_hosts and >> >> > update_cell >> >> > >> >> > the output from: nova-manage cell_v2 list_hosts >> >> > +-----------+--------------------------------------+-------------+ >> >> > | Cell Name | Cell UUID | Hostname | >> >> > +-----------+--------------------------------------+-------------+ >> >> > | None | 1a0fde85-8906-46fb-b721-01a28c978439 | computenode | >> >> > | None | 1a0fde85-8906-46fb-b721-01a28c978439 | nrUE | >> >> > | cell1 | 1522c22f-64d4-4882-8ae8-ed0f9407407c | openstack | >> >> > +-----------+--------------------------------------+-------------+ >> >> > >> >> > when the new compute nodes seem to not have a cell mapped >> >> > >> >> > best, >> >> > P. >> >> > >> >> > >> >> > On Wed, Nov 11, 2020 at 3:26 PM Eugen Block wrote: >> >> > >> >> >> Hm, >> >> >> >> >> >> indeed rather strange to me. >> >> >> >> >> >> Do you see anything in the nova-scheduler.log? If you activated the >> >> >> >> >> >> discover_hosts_in_cells_interval = 300 >> >> >> >> >> >> it should query for new hosts every 5 minutes. >> >> >> >> >> >> >> >> >> >> >> >> Zitat von Pavlos Basaras : >> >> >> >> >> >> > Hello, >> >> >> > >> >> >> > thanks very much for your prompt reply. >> >> >> > >> >> >> > >> >> >> > regarding the first command "nova-manage cell_v2 list_hosts" the >> >> output >> >> >> is >> >> >> > the following (openstack is the host of the controller). I dont see >> >> any >> >> >> > other node here, even when i execute the discover_hosts command >> >> >> > >> >> >> > +-----------+--------------------------------------+-----------+ >> >> >> > | Cell Name | Cell UUID | Hostname | >> >> >> > +-----------+--------------------------------------+-----------+ >> >> >> > | cell1 | 1522c22f-64d4-4882-8ae8-ed0f9407407c | openstack | >> >> >> > +-----------+--------------------------------------+-----------+ >> >> >> > >> >> >> > >> >> >> > Also this is the output from my controller when i use the command: >> >> sudo >> >> >> -s >> >> >> > /bin/sh -c "nova-manage cell_v2 discover_hosts --verbose" nova >> (not >> >> >> sure >> >> >> > if this helps) >> >> >> > Found 2 cell mappings. >> >> >> > Skipping cell0 since it does not contain hosts. >> >> >> > Getting computes from cell 'cell1': >> >> 1522c22f-64d4-4882-8ae8-ed0f9407407c >> >> >> > Found 0 unmapped computes in cell: >> >> 1522c22f-64d4-4882-8ae8-ed0f9407407c >> >> >> > >> >> >> > any thoughts? >> >> >> > >> >> >> > >> >> >> > best, >> >> >> > Pavlos. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> From dev.faz at gmail.com Fri Nov 13 08:21:59 2020 From: dev.faz at gmail.com (Fabian Zimmermann) Date: Fri, 13 Nov 2020 09:21:59 +0100 Subject: [neutron] BaGPipe experiences In-Reply-To: References: Message-ID: Hi, we use it in production and it works quite well. We run 2 agents and only have some issues with lost agent-network-bundings if rabbitmq nodes fail. Fabian Michael Richardson schrieb am Do., 12. Nov. 2020, 21:48: > Hi all, > > Is anyone using the BaGPipe driver[0] in production? Any comments, > experiences, config. recommendations, war stories, tales of caution you > would like to share? > > Cheers, > > Michael > > [0] https://docs.openstack.org/networking-bagpipe/latest/ > > > -- > Michael Richardson > Catalyst Cloud || Catalyst IT Limited > https://catalystcloud.nz/ > GPG: 0530 4686 F996 4E2C 5DC7 6327 5C98 5EED A30 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From geguileo at redhat.com Fri Nov 13 09:23:27 2020 From: geguileo at redhat.com (Gorka Eguileor) Date: Fri, 13 Nov 2020 10:23:27 +0100 Subject: [cinder][ops] restricting the Ceph version used with Cinder In-Reply-To: References: Message-ID: <20201113092327.dbyyiwwwcdwkon62@localhost> On 13/11, Tobias Urdin wrote: > Hello Brian, > > Thanks for the information! Really appreciate that it’s communicated properly. > > I have a question, I think it’s a little harsh to constraint deployments needing the same release for server and client when The Ceph project itself guarantees backward compatibility. What is the reasoning behind this and will Cinder upstream ensure that upgrade paths between Ceph releases are not broken? > > Best regards Hi, I believe there are multiple reasons to require alignment: - Without it a system could be using a Luminous client without support for a Mimic feature that Cinder wants to use. - If a really old client has a known bug that won't be fixed, because it's no longer supported, we would have to include a workaround in Cinder for them all, whereas now we would only have to do it for a limited number of versions. - Backward compatibility at the CLI level doesn't necessarily mean backward compatibility at the library level. - As far as I know, the CI uses aligned versions, so that's what we can be sure works. I'm sure there are other, and probably better, reasons, but in any case, this reduces the possible combinations of clients-servers that need to be supported. As far as the Ceph upgrade paths, I believe upstream Cinder will stay out of it and let it be a Ceph matter. Cheers, Gorka. > > > On 13 Nov 2020, at 01:00, Brian Rosmaita wrote: > > > > The Cinder project plans to take advantage of recent developments in Ceph to make some improvements to the RBD driver. To do that, we propose restricting the Cinder-supported releases of Ceph to the active stable releases plus the two prior releases. > > > > This will make Mimic the minimum supported version of Ceph for the Wallaby and X releases of Cinder. > > > > This is explained in a bit more detail in a patch to the RBD driver documentation: > > https://review.opendev.org/#/c/762592/ > > > > If you have concerns about this proposal, please leave comments on the review. > > > > Thank you, > > brian > > From balazs.gibizer at est.tech Fri Nov 13 10:05:56 2020 From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer) Date: Fri, 13 Nov 2020 11:05:56 +0100 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: <4211161605171577@mail.yandex.ru> References: <4211161605171577@mail.yandex.ru> Message-ID: On Thu, Nov 12, 2020 at 11:18, Dmitriy Rabotyagov wrote: > Hi, > > Well, while OSA really place DB credentials into nova.conf only when > needed, this patch will still break our all-in-one setup. I have > nothing against approach of > the separating config files, but I'm sure this needs to be really > well documented. Also would be great to have list of options that are > required for nova-compute > to work. As then it makes sense to do nova-compute.conf as minimal as > possible and exclude all scheduler and placement bits from it as well > (and libvirt > from scheduler/api part of the conf). I've filed a doc bug in nova[1] to improve the documentation about the mandatory minimal config for each service. Some background discussion also happened on the nova meeting[2] yesterday. Cheers, gibi [1] https://bugs.launchpad.net/nova/+bug/1904179 [2] http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-11-12-16.00.log.html#l-167 From balazs.gibizer at est.tech Fri Nov 13 10:06:01 2020 From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer) Date: Fri, 13 Nov 2020 11:06:01 +0100 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: <864396842.58157343.1605179360197.JavaMail.zimbra@redhat.com> References: <864396842.58157343.1605179360197.JavaMail.zimbra@redhat.com> Message-ID: <12CQJQ.RNX7AJ4TRBJ21@est.tech> On Thu, Nov 12, 2020 at 06:09, Javier Pena wrote: >> On 11/11/20 5:35 PM, Balázs Gibizer wrote: >> > Dear packagers and deployment engine developers, >> > >> > Since Icehouse nova-compute service does not need any database >> > configuration as it uses the message bus to access data in the >> database >> > via the conductor service. Also, the nova configuration guide >> states >> > that the nova-compute service should not have the >> > [api_database]connection config set. Having any DB credentials >> > configured for the nova-compute is a security risk as well since >> that >> > service runs close to the hypervisor. Since Rocky[1] nova-compute >> > service fails if you configure API DB credentials and set >> upgrade_level >> > config to 'auto'. >> > >> > Now we are proposing a patch[2] that makes nova-compute fail at >> startup >> > if the [database]connection or the [api_database]connection is >> > configured. We know that this breaks at least the rpm packaging, >> debian >> > packaging, and puppet-nova. The problem there is that in an >> all-in-on >> > deployment scenario the nova.conf file generated by these tools is >> > shared between all the nova services and therefore nova-compute >> sees DB >> > credentials. As a counter-example, devstack generates a separate >> > nova-cpu.conf and passes that to the nova-compute service even in >> an >> > all-in-on setup. >> > >> > The nova team would like to merge [2] during Wallaby but we are >> OK to >> > delay the patch until Wallaby Milestone 2 so that the packagers >> and >> > deployment tools can catch up. Please let us know if you are >> impacted >> > and provide a way to track when you are ready with the >> modification that >> > allows [2] to be merged. >> > >> > There was a long discussion on #openstack-nova today[3] around >> this >> > topic. So you can find more detailed reasoning there[3]. >> > >> > Cheers, >> > gibi >> >> IMO, that's ok if, and only if, we all agree on how to implement it. >> Best would be if we (all downstream distro + config management) >> agree on >> how to implement this. >> >> How about, we all implement a /etc/nova/nova-db.conf, and get all >> services that need db access to use it (ie: starting them with >> --config-file=/etc/nova/nova-db.conf)? >> > > Hi, > > This is going to be an issue for those services we run as a WSGI app. > Looking at [1], I see > the app has a hardcoded list of config files to read (api-paste.ini > and nova.conf), so we'd > need to modify it at the installer level. > > Personally, I like the nova-db.conf way, since it looks like it > reduces the amount of work > required for all-in-one installers to adapt, but that requires some > code change. Would the > Nova team be happy with adding a nova-db.conf file to that list? Devstack solves the all-in-one case by using these config files: * nova.conf and api_paste.ini for the wsgi apps e.g. nova-api and nova-metadata-api * nova.conf for the nova-scheduler and the top level nova-conductor (super conductor) * nova-cell.conf for the cell level nova-conductor and the proxy services, e.g. nova-novncproxy * nova-cpu.conf for the nova-compute service The nova team suggest to use a similar strategy to separate files. So at the moment we are not planning to change what config files the wsgi apps will read. Cheers, gibi > > Regards, > Javier > > > [1] - > https://opendev.org/openstack/nova/src/branch/master/nova/api/openstack/wsgi_app.py#L30 > >> If I understand well, these services would need access to db: >> - conductor >> - scheduler >> - novncproxy >> - serialproxy >> - spicehtml5proxy >> - api >> - api-metadata >> >> Is this list correct? Or is there some services that also don't >> need it? >> >> Cheers, >> >> Thomas Goirand (zigo) >> >> > > From hberaud at redhat.com Fri Nov 13 10:32:42 2020 From: hberaud at redhat.com (Herve Beraud) Date: Fri, 13 Nov 2020 11:32:42 +0100 Subject: [release][masakari] - [Release-job-failures] Release of openstack/masakari-monitors for ref refs/tags/(7.0.1|8.0.2|9.0.1) failed Message-ID: During the release job for: - masakari-monitors 9.0.1 (ussuri) - masakari-monitors 8.0.2 (train) - masakari-monitors 7.0.1 (stein) uploads to PyPI failed [1][2][3] with: "No package matching 'python-libvirt' is available" [4][5][6] It's due to our recent move to focal [7] where the package 'python-libvirt' is named ''python3-libvirt'.This package is pulled by bindep during the job execution. Current status: Tag (9.0.1, 8.0.2, 7.0.1) was pushed OK No tarball upload No PyPI upload Once the issue is fixed, a new version should be released for the three stables branches. Version 9.0.1, 8.0.2, 7.0.1 these versions will never be uploaded on PyPi as the fix requires new changes in the project repo [8][9][10]. Also notice that on Victoria and Wallaby this bindep requirement have been dropped during the migration testing on ubuntu focal [11]. [1] https://zuul.opendev.org/t/openstack/build/63539177d44b4ea48d3fbfe39a638275/log/job-output.txt#348 [2] https://zuul.opendev.org/t/openstack/build/778ace86ec8f4ef894d740d81e8f700f/log/job-output.txt#349 [3] https://zuul.opendev.org/t/openstack/build/919cfc7df1e0408e9d6af4a9e8ef28ee/log/job-output.txt#347 [4] http://lists.openstack.org/pipermail/release-job-failures/2020-November/001484.html [5] http://lists.openstack.org/pipermail/release-job-failures/2020-November/001485.html [6] http://lists.openstack.org/pipermail/release-job-failures/2020-November/001486.html [7] http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018585.html [8] https://opendev.org/openstack/masakari-monitors/src/branch/stable/stein/bindep.txt#L6 [9] https://opendev.org/openstack/masakari-monitors/src/branch/stable/train/bindep.txt#L6 [10] https://opendev.org/openstack/masakari-monitors/src/branch/stable/ussuri/bindep.txt#L6 [11] https://opendev.org/openstack/masakari-monitors/commit/03ef3555888fdd0ea38b4edfdc093382071f1031 -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jocelyn.thode at elca.ch Fri Nov 13 10:50:09 2020 From: jocelyn.thode at elca.ch (Thode Jocelyn) Date: Fri, 13 Nov 2020 10:50:09 +0000 Subject: CloudKitty deployment on Train and/or Ussuri In-Reply-To: References: Message-ID: <29a0ff29af9d4314bdc2e0b2bc69cc8f@elca.ch> Hi Henry, Unfortunately as I did not get any answer I had stop investigating cloud kitty for the moment, so I was not able to make cloudkitty-api work. For now we have put this task in standby and looking at other alternatives from afar. Let me know if you make any progress on your end. I'll let you know if we start working again on Cloudkitty on our side Cheers Jocelyn -----Original Message----- From: Henry Bonath Sent: mardi, 10 novembre 2020 21:24 To: Thode Jocelyn Cc: openstack-discuss at lists.openstack.org Subject: Re: CloudKitty deployment on Train and/or Ussuri Hi Jocelyn, I am also an Openstack-Ansible user, who is in the same market of trying to find Rating-as-A-Service for my Train cloud. I stumbled upon your message here after running into the same exact issue that you are having and searching for answers, and am glad to hear that I am not alone. (Don't you hate when you only find more questions??) I am testing Cloudkitty v13.0.0 right now and running into the same issue as you are as it relates to 'cloudkitty-api'. I also found that the templated config you referenced needs to be updated as well. I'm going to continue to soldier through this and try to get a working configuration, were you able to make any progress on the issue with cloudkitty-api? Please let me know if we can work together to get this working, I can submit any patches to the openstack-ansible-os_cloudkitty repo. -Henry On Fri, Oct 23, 2020 at 2:38 AM Thode Jocelyn wrote: > > Hi, > > > > I was looking at the possibilities to have Rating-as-A-Service in our > Openstack (currently train but planning to move to Ussuri) and I > stumbled upon CloudKitty. I’m currently facing multiple issues with > cloudkitty itself and with openstack-ansible. (We are using a > containerized deployment with LXC) > > > > I noticed that openstack-ansible has no playbook yet to install a service like CloudKitty even though starting from Ussuri it was added in the ansible-role-requirements.yml. I have created a small patch to be able to install CloudKitty via openstack-ansible and if this is of interest I could potentially submit a PR with this. > The os_cloudkitty role seems to kinda work and only with a relatively old version of CloudKitty. For example, here : https://opendev.org/openstack/openstack-ansible-os_cloudkitty/src/branch/stable/train/templates/cloudkitty.conf.j2#L38 since CloudKitty v8.0.0 the section should be named “[fetcher_keystone]”, but I found no information as to which CloudKitty version should be used with this role. Does someone have any recommendation as to which version should be used and if there is any interest in improving the role to support more recent versions of CloudKitty? > Even when tweaking the configuration and installing v7.0.0 of Cloudkitty it only fixes cloudkitty-processor, I was never able to make cloudkitty-api work I always get an error like “Fatal Python error: Py_Initialize: Unable to get the locale encoding ModuleNotFoundError: No module named 'encodings'”. Any input on this would be greatly appreciated. > > > > > Cheers > > Jocelyn From radoslaw.piliszek at gmail.com Fri Nov 13 10:56:47 2020 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Fri, 13 Nov 2020 11:56:47 +0100 Subject: [release][masakari] - [Release-job-failures] Release of openstack/masakari-monitors for ref refs/tags/(7.0.1|8.0.2|9.0.1) failed In-Reply-To: References: Message-ID: On Fri, Nov 13, 2020 at 11:35 AM Herve Beraud wrote: > > During the release job for: > - masakari-monitors 9.0.1 (ussuri) > - masakari-monitors 8.0.2 (train) > - masakari-monitors 7.0.1 (stein) > > uploads to PyPI failed [1][2][3] with: > > "No package matching 'python-libvirt' is available" [4][5][6] > > It's due to our recent move to focal [7] where the package 'python-libvirt' is named ''python3-libvirt'.This package is pulled by bindep during the job execution. > > Current status: > Tag (9.0.1, 8.0.2, 7.0.1) was pushed OK > No tarball upload > No PyPI upload > > Once the issue is fixed, a new version should be released for the three stables branches. > > Version 9.0.1, 8.0.2, 7.0.1 these versions will never be uploaded on PyPi as the fix requires new changes in the project repo [8][9][10]. > > Also notice that on Victoria and Wallaby this bindep requirement have been dropped during the migration testing on ubuntu focal [11]. > > [1] https://zuul.opendev.org/t/openstack/build/63539177d44b4ea48d3fbfe39a638275/log/job-output.txt#348 > [2] https://zuul.opendev.org/t/openstack/build/778ace86ec8f4ef894d740d81e8f700f/log/job-output.txt#349 > [3] https://zuul.opendev.org/t/openstack/build/919cfc7df1e0408e9d6af4a9e8ef28ee/log/job-output.txt#347 > [4] http://lists.openstack.org/pipermail/release-job-failures/2020-November/001484.html > [5] http://lists.openstack.org/pipermail/release-job-failures/2020-November/001485.html > [6] http://lists.openstack.org/pipermail/release-job-failures/2020-November/001486.html > [7] http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018585.html > [8] https://opendev.org/openstack/masakari-monitors/src/branch/stable/stein/bindep.txt#L6 > [9] https://opendev.org/openstack/masakari-monitors/src/branch/stable/train/bindep.txt#L6 > [10] https://opendev.org/openstack/masakari-monitors/src/branch/stable/ussuri/bindep.txt#L6 > [11] https://opendev.org/openstack/masakari-monitors/commit/03ef3555888fdd0ea38b4edfdc093382071f1031 > Thanks, Hervé. I will just drop this from bindep as it should not be there in the first place (bindep really meaning system-level packages not available from PyPI, usually because they are not Python packages). -yoctozepto From hberaud at redhat.com Fri Nov 13 11:09:28 2020 From: hberaud at redhat.com (Herve Beraud) Date: Fri, 13 Nov 2020 12:09:28 +0100 Subject: [release][masakari] - [Release-job-failures] Release of openstack/masakari-monitors for ref refs/tags/(7.0.1|8.0.2|9.0.1) failed In-Reply-To: References: Message-ID: Thanks for the heads up. Notice that I just submitted a series of patches [1] to fix all masakari's stable branches, feel free to abandon these patches if they aren't needed anymore. [1] https://review.opendev.org/#/q/topic:fix-libvirt-focal+(status:open+OR+status:merged) Le ven. 13 nov. 2020 à 11:57, Radosław Piliszek a écrit : > On Fri, Nov 13, 2020 at 11:35 AM Herve Beraud wrote: > > > > During the release job for: > > - masakari-monitors 9.0.1 (ussuri) > > - masakari-monitors 8.0.2 (train) > > - masakari-monitors 7.0.1 (stein) > > > > uploads to PyPI failed [1][2][3] with: > > > > "No package matching 'python-libvirt' is available" [4][5][6] > > > > It's due to our recent move to focal [7] where the package > 'python-libvirt' is named ''python3-libvirt'.This package is pulled by > bindep during the job execution. > > > > Current status: > > Tag (9.0.1, 8.0.2, 7.0.1) was pushed OK > > No tarball upload > > No PyPI upload > > > > Once the issue is fixed, a new version should be released for the three > stables branches. > > > > Version 9.0.1, 8.0.2, 7.0.1 these versions will never be uploaded on > PyPi as the fix requires new changes in the project repo [8][9][10]. > > > > Also notice that on Victoria and Wallaby this bindep requirement have > been dropped during the migration testing on ubuntu focal [11]. > > > > [1] > https://zuul.opendev.org/t/openstack/build/63539177d44b4ea48d3fbfe39a638275/log/job-output.txt#348 > > [2] > https://zuul.opendev.org/t/openstack/build/778ace86ec8f4ef894d740d81e8f700f/log/job-output.txt#349 > > [3] > https://zuul.opendev.org/t/openstack/build/919cfc7df1e0408e9d6af4a9e8ef28ee/log/job-output.txt#347 > > [4] > http://lists.openstack.org/pipermail/release-job-failures/2020-November/001484.html > > [5] > http://lists.openstack.org/pipermail/release-job-failures/2020-November/001485.html > > [6] > http://lists.openstack.org/pipermail/release-job-failures/2020-November/001486.html > > [7] > http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018585.html > > [8] > https://opendev.org/openstack/masakari-monitors/src/branch/stable/stein/bindep.txt#L6 > > [9] > https://opendev.org/openstack/masakari-monitors/src/branch/stable/train/bindep.txt#L6 > > [10] > https://opendev.org/openstack/masakari-monitors/src/branch/stable/ussuri/bindep.txt#L6 > > [11] > https://opendev.org/openstack/masakari-monitors/commit/03ef3555888fdd0ea38b4edfdc093382071f1031 > > > > Thanks, Hervé. > > I will just drop this from bindep as it should not be there in the > first place (bindep really meaning system-level packages not available > from PyPI, usually because they are not Python packages). > > -yoctozepto > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre at stackhpc.com Fri Nov 13 11:28:26 2020 From: pierre at stackhpc.com (Pierre Riteau) Date: Fri, 13 Nov 2020 12:28:26 +0100 Subject: CloudKitty deployment on Train and/or Ussuri In-Reply-To: <29a0ff29af9d4314bdc2e0b2bc69cc8f@elca.ch> References: <29a0ff29af9d4314bdc2e0b2bc69cc8f@elca.ch> Message-ID: Hi Thode and Henry, The CloudKitty role in OSA is using configuration options that were deprecated back in 9.0.0 (Stein) and deleted in 11.0.0 (Train). As I am not an OSA user (I use Kolla Ansible which supports CloudKitty well), I encourage you to submit your fixes to OSA. About the error you are seeing in cloudkitty-api, I haven't seen this before. Could you give more information about your deployment? Are you using a packaged version (deb / rpm) or source? What is your Linux distribution? Best wishes, Pierre Riteau (priteau) On Fri, 13 Nov 2020 at 11:50, Thode Jocelyn wrote: > Hi Henry, > > Unfortunately as I did not get any answer I had stop investigating cloud > kitty for the moment, so I was not able to make cloudkitty-api work. For > now we have put this task in standby and looking at other alternatives from > afar. > > Let me know if you make any progress on your end. I'll let you know if we > start working again on Cloudkitty on our side > > Cheers > Jocelyn > > -----Original Message----- > From: Henry Bonath > Sent: mardi, 10 novembre 2020 21:24 > To: Thode Jocelyn > Cc: openstack-discuss at lists.openstack.org > Subject: Re: CloudKitty deployment on Train and/or Ussuri > > Hi Jocelyn, > > I am also an Openstack-Ansible user, who is in the same market of trying > to find Rating-as-A-Service for my Train cloud. > I stumbled upon your message here after running into the same exact issue > that you are having and searching for answers, and am glad to hear that I > am not alone. > (Don't you hate when you only find more questions??) > > I am testing Cloudkitty v13.0.0 right now and running into the same issue > as you are as it relates to 'cloudkitty-api'. > I also found that the templated config you referenced needs to be updated > as well. > > I'm going to continue to soldier through this and try to get a working > configuration, were you able to make any progress on the issue with > cloudkitty-api? > Please let me know if we can work together to get this working, I can > submit any patches to the openstack-ansible-os_cloudkitty repo. > > -Henry > > On Fri, Oct 23, 2020 at 2:38 AM Thode Jocelyn > wrote: > > > > Hi, > > > > > > > > I was looking at the possibilities to have Rating-as-A-Service in our > > Openstack (currently train but planning to move to Ussuri) and I > > stumbled upon CloudKitty. I’m currently facing multiple issues with > > cloudkitty itself and with openstack-ansible. (We are using a > > containerized deployment with LXC) > > > > > > > > I noticed that openstack-ansible has no playbook yet to install a > service like CloudKitty even though starting from Ussuri it was added in > the ansible-role-requirements.yml. I have created a small patch to be able > to install CloudKitty via openstack-ansible and if this is of interest I > could potentially submit a PR with this. > > The os_cloudkitty role seems to kinda work and only with a relatively > old version of CloudKitty. For example, here : > https://opendev.org/openstack/openstack-ansible-os_cloudkitty/src/branch/stable/train/templates/cloudkitty.conf.j2#L38 > since CloudKitty v8.0.0 the section should be named “[fetcher_keystone]”, > but I found no information as to which CloudKitty version should be used > with this role. Does someone have any recommendation as to which version > should be used and if there is any interest in improving the role to > support more recent versions of CloudKitty? > > Even when tweaking the configuration and installing v7.0.0 of Cloudkitty > it only fixes cloudkitty-processor, I was never able to make cloudkitty-api > work I always get an error like “Fatal Python error: Py_Initialize: Unable > to get the locale encoding ModuleNotFoundError: No module named > 'encodings'”. Any input on this would be greatly appreciated. > > > > > > > > > > Cheers > > > > Jocelyn > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Fri Nov 13 11:32:06 2020 From: hberaud at redhat.com (Herve Beraud) Date: Fri, 13 Nov 2020 12:32:06 +0100 Subject: [release][masakari] - [Release-job-failures] Release of openstack/masakari-monitors for ref refs/tags/(7.0.1|8.0.2|9.0.1) failed In-Reply-To: References: Message-ID: Potentially all the following repos should be fixed to avoid the same issue with their stable branches: - https://opendev.org/openstack/monasca-agent/ - https://opendev.org/openstack/release-test/src/branch/master/bindep.txt - https://opendev.org/openstack/training-labs Also notice that the following projects that doesn't have stable branches so I think they could be ignored: - https://opendev.org/openstack/reviewday/ - https://opendev.org/openstack/js-openstack-lib/ FYI the previous list is a filtered version of the results obtained by using: ``` beagle search --ignore-comments -f link --file '(^bindep.txt)' --repo-pattern "openstack/*" 'python-libvirt' https://opendev.org/openstack/js-openstack-lib/src/branch/master/bindep.txt#n30 : python-libvirt [platform:dpkg] https://opendev.org/openstack/monasca-agent/src/branch/master/bindep.txt#n46 : python-libvirt [platform:dpkg !platform:ubuntu-focal] https://opendev.org/openstack/release-test/src/branch/master/bindep.txt#n17 : python-libvirt [platform:dpkg] https://opendev.org/openstack/reviewday/src/branch/master/bindep.txt#n10 : python-libvirt [platform:dpkg] https://opendev.org/openstack/training-labs/src/branch/master/bindep.txt#n48 : python-libvirt [platform:dpkg] ``` Le ven. 13 nov. 2020 à 12:09, Herve Beraud a écrit : > Thanks for the heads up. > > Notice that I just submitted a series of patches [1] to fix all > masakari's stable branches, feel free to abandon these patches if they > aren't needed anymore. > > [1] > https://review.opendev.org/#/q/topic:fix-libvirt-focal+(status:open+OR+status:merged) > > Le ven. 13 nov. 2020 à 11:57, Radosław Piliszek < > radoslaw.piliszek at gmail.com> a écrit : > >> On Fri, Nov 13, 2020 at 11:35 AM Herve Beraud wrote: >> > >> > During the release job for: >> > - masakari-monitors 9.0.1 (ussuri) >> > - masakari-monitors 8.0.2 (train) >> > - masakari-monitors 7.0.1 (stein) >> > >> > uploads to PyPI failed [1][2][3] with: >> > >> > "No package matching 'python-libvirt' is available" [4][5][6] >> > >> > It's due to our recent move to focal [7] where the package >> 'python-libvirt' is named ''python3-libvirt'.This package is pulled by >> bindep during the job execution. >> > >> > Current status: >> > Tag (9.0.1, 8.0.2, 7.0.1) was pushed OK >> > No tarball upload >> > No PyPI upload >> > >> > Once the issue is fixed, a new version should be released for the three >> stables branches. >> > >> > Version 9.0.1, 8.0.2, 7.0.1 these versions will never be uploaded on >> PyPi as the fix requires new changes in the project repo [8][9][10]. >> > >> > Also notice that on Victoria and Wallaby this bindep requirement have >> been dropped during the migration testing on ubuntu focal [11]. >> > >> > [1] >> https://zuul.opendev.org/t/openstack/build/63539177d44b4ea48d3fbfe39a638275/log/job-output.txt#348 >> > [2] >> https://zuul.opendev.org/t/openstack/build/778ace86ec8f4ef894d740d81e8f700f/log/job-output.txt#349 >> > [3] >> https://zuul.opendev.org/t/openstack/build/919cfc7df1e0408e9d6af4a9e8ef28ee/log/job-output.txt#347 >> > [4] >> http://lists.openstack.org/pipermail/release-job-failures/2020-November/001484.html >> > [5] >> http://lists.openstack.org/pipermail/release-job-failures/2020-November/001485.html >> > [6] >> http://lists.openstack.org/pipermail/release-job-failures/2020-November/001486.html >> > [7] >> http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018585.html >> > [8] >> https://opendev.org/openstack/masakari-monitors/src/branch/stable/stein/bindep.txt#L6 >> > [9] >> https://opendev.org/openstack/masakari-monitors/src/branch/stable/train/bindep.txt#L6 >> > [10] >> https://opendev.org/openstack/masakari-monitors/src/branch/stable/ussuri/bindep.txt#L6 >> > [11] >> https://opendev.org/openstack/masakari-monitors/commit/03ef3555888fdd0ea38b4edfdc093382071f1031 >> > >> >> Thanks, Hervé. >> >> I will just drop this from bindep as it should not be there in the >> first place (bindep really meaning system-level packages not available >> from PyPI, usually because they are not Python packages). >> >> -yoctozepto >> >> > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From gokhan.isik at tubitak.gov.tr Fri Nov 13 11:51:14 2020 From: gokhan.isik at tubitak.gov.tr (=?utf-8?Q?G=C3=B6khan_I=C5=9EIK_-_T=C3=9CB=C4=B0TAK_B=C4=B0LGEM?=) Date: Fri, 13 Nov 2020 14:51:14 +0300 (EET) Subject: CloudKitty deployment on Train and/or Ussuri In-Reply-To: References: <29a0ff29af9d4314bdc2e0b2bc69cc8f@elca.ch> Message-ID: <442787327.5847224.1605268274504.JavaMail.zimbra@tubitak.gov.tr> Hi Thode and Pierre, I am also an OSA user. We are using cloudkitty in our pike environment. we are now upgrading our environment to ussuri version. We are planning to use cloudkitty again. At pike version, ı have some updates on cloudkitty role[1]. ı will work on cloudkitty ussuri version next week. We can make cloudkitty run. We can contact on #openstack-ansible irc channel. ı hope we can make cloudkitty run successfully. [1] https://github.com/b3lab/openstack-ansible-os_cloudkitty/tree/stable/pike/ Best wishes, Gökhan IŞIK (gokhani) Kimden: "Pierre Riteau" Kime: "Thode Jocelyn" Kk: "Henry Bonath" , openstack-discuss at lists.openstack.org Gönderilenler: 13 Kasım Cuma 2020 14:28:26 Konu: Re: CloudKitty deployment on Train and/or Ussuri Thode Hi Thode and Henry, The CloudKitty role in OSA is using configuration options that were deprecated back in 9.0.0 (Stein) and deleted in 11.0.0 (Train). As I am not an OSA user (I use Kolla Ansible which supports CloudKitty well), I encourage you to submit your fixes to OSA. About the error you are seeing in cloudkitty-api, I haven't seen this before. Could you give more information about your deployment? Are you using a packaged version (deb / rpm) or source? What is your Linux distribution? Best wishes, Pierre Riteau (priteau) On Fri, 13 Nov 2020 at 11:50, Thode Jocelyn < [ mailto:jocelyn.thode at elca.ch | jocelyn.thode at elca.ch ] > wrote: Hi Henry, Unfortunately as I did not get any answer I had stop investigating cloud kitty for the moment, so I was not able to make cloudkitty-api work. For now we have put this task in standby and looking at other alternatives from afar. Let me know if you make any progress on your end. I'll let you know if we start working again on Cloudkitty on our side Cheers Jocelyn -----Original Message----- From: Henry Bonath < [ mailto:henry at thebonaths.com | henry at thebonaths.com ] > Sent: mardi, 10 novembre 2020 21:24 To: Thode Jocelyn < [ mailto:jocelyn.thode at elca.ch | jocelyn.thode at elca.ch ] > Cc: [ mailto:openstack-discuss at lists.openstack.org | openstack-discuss at lists.openstack.org ] Subject: Re: CloudKitty deployment on Train and/or Ussuri Hi Jocelyn, I am also an Openstack-Ansible user, who is in the same market of trying to find Rating-as-A-Service for my Train cloud. I stumbled upon your message here after running into the same exact issue that you are having and searching for answers, and am glad to hear that I am not alone. (Don't you hate when you only find more questions??) I am testing Cloudkitty v13.0.0 right now and running into the same issue as you are as it relates to 'cloudkitty-api'. I also found that the templated config you referenced needs to be updated as well. I'm going to continue to soldier through this and try to get a working configuration, were you able to make any progress on the issue with cloudkitty-api? Please let me know if we can work together to get this working, I can submit any patches to the openstack-ansible-os_cloudkitty repo. -Henry On Fri, Oct 23, 2020 at 2:38 AM Thode Jocelyn < [ mailto:jocelyn.thode at elca.ch | jocelyn.thode at elca.ch ] > wrote: > > Hi, > > > > I was looking at the possibilities to have Rating-as-A-Service in our > Openstack (currently train but planning to move to Ussuri) and I > stumbled upon CloudKitty. I’m currently facing multiple issues with > cloudkitty itself and with openstack-ansible. (We are using a > containerized deployment with LXC) > > > > I noticed that openstack-ansible has no playbook yet to install a service like CloudKitty even though starting from Ussuri it was added in the ansible-role-requirements.yml. I have created a small patch to be able to install CloudKitty via openstack-ansible and if this is of interest I could potentially submit a PR with this. > The os_cloudkitty role seems to kinda work and only with a relatively old version of CloudKitty. For example, here : [ https://opendev.org/openstack/openstack-ansible-os_cloudkitty/src/branch/stable/train/templates/cloudkitty.conf.j2#L38 | https://opendev.org/openstack/openstack-ansible-os_cloudkitty/src/branch/stable/train/templates/cloudkitty.conf.j2#L38 ] since CloudKitty v8.0.0 the section should be named “[fetcher_keystone]”, but I found no information as to which CloudKitty version should be used with this role. Does someone have any recommendation as to which version should be used and if there is any interest in improving the role to support more recent versions of CloudKitty? > Even when tweaking the configuration and installing v7.0.0 of Cloudkitty it only fixes cloudkitty-processor, I was never able to make cloudkitty-api work I always get an error like “Fatal Python error: Py_Initialize: Unable to get the locale encoding ModuleNotFoundError: No module named 'encodings'”. Any input on this would be greatly appreciated. > > > > > Cheers > > Jocelyn -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafaelweingartner at gmail.com Fri Nov 13 12:16:36 2020 From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=) Date: Fri, 13 Nov 2020 09:16:36 -0300 Subject: [telemetry] wallaby cycle planning session In-Reply-To: References: Message-ID: I answered your doodle poll there. I think that we can work together to find a solution for this unfortunate situation. Keep me updated with the results of the poll. On Thu, Nov 12, 2020 at 7:29 AM Matthias Runge wrote: > Hi there, > > one of the biggest challenges for the telemetry stack is currently the > state of gnocchi, which is... undefined/unfortunate/under-contributed/...? > > Telemetry started long time ago as a simple component ceilometer, which > was split into several components ceilometer, aodh, panko, and gnocchi. > Julien wrote a story about this some time ago[1]. > > There has also been an attempt to fork gnocchi back to OpenStack[2]. > > To my knowledge, the original contributors are not paid anymore to work > on gnocchi, and at the same time, moving on to do something else is > totally fine. > > However, I am not sure if we (in OpenStack Telemetry) should or could > maintain in addition to the rest of the telemetry stack a time-series > database. I'd like to discuss this during a call. > > Please select time(s) that suit you best in this poll[3]. > > If you have questions or hints, don't hesitate to contact me. > > Thank you, > Matthias > > [1] https://julien.danjou.info/lessons-from-openstack-telemetry-deflation/ > [2] https://review.opendev.org/#/c/744592/ > [3] https://doodle.com/poll/uqq328x5shr43awy > > -- Rafael Weingärtner -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Fri Nov 13 12:17:09 2020 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Fri, 13 Nov 2020 13:17:09 +0100 Subject: [release][masakari] - [Release-job-failures] Release of openstack/masakari-monitors for ref refs/tags/(7.0.1|8.0.2|9.0.1) failed In-Reply-To: References: Message-ID: On Fri, Nov 13, 2020 at 12:09 PM Herve Beraud wrote: > > Thanks for the heads up. > > Notice that I just submitted a series of patches [1] to fix all masakari's stable branches, feel free to abandon these patches if they aren't needed anymore. > > [1] https://review.opendev.org/#/q/topic:fix-libvirt-focal+(status:open+OR+status:merged) > Ah, sorry, did not notice that. I just went with [1] removing the pkg to avoid the naming issue altogether. My question is whether we could detect such issues more proactively? [1] https://review.opendev.org/762637 -yoctozepto From hberaud at redhat.com Fri Nov 13 12:45:54 2020 From: hberaud at redhat.com (Herve Beraud) Date: Fri, 13 Nov 2020 13:45:54 +0100 Subject: [release][masakari] - [Release-job-failures] Release of openstack/masakari-monitors for ref refs/tags/(7.0.1|8.0.2|9.0.1) failed In-Reply-To: References: Message-ID: Le ven. 13 nov. 2020 à 13:17, Radosław Piliszek a écrit : > On Fri, Nov 13, 2020 at 12:09 PM Herve Beraud wrote: > > > > Thanks for the heads up. > > > > Notice that I just submitted a series of patches [1] to fix all > masakari's stable branches, feel free to abandon these patches if they > aren't needed anymore. > > > > [1] > https://review.opendev.org/#/q/topic:fix-libvirt-focal+(status:open+OR+status:merged) > > > > Ah, sorry, did not notice that. > I just went with [1] removing the pkg to avoid the naming issue altogether. > No problem > My question is whether we could detect such issues more proactively? > Good question... I don't think that this kind of a check should be hosted on the release management side. Here our issue is more an environment issue, It's due to the fact that we decided to run the job `publish-openstack-artifacts` on ubuntu-focal, so to detect this kind of issue early I think that jobs on the projects side should rely on ubuntu-focal too. I'm not a Zuul expert and I don't know if it is possible to add a condition based on the branches (per example) to choose the right env (focal or not). By following this way I guess it could be possible to fail early on the project side, and it could allow you to fix this kind of issue well before proposing a new release. In other words, if projects's jobs env are aligned with release management our job we could catch them early. We have other scenarios to consider. These are when no patches haven't been merged since a while on projects side, and where a release is proposed, in this case even if environments are aligned, in this case we aren't able to detect this kind of issue, and they will continue to occur during publication, as in this case. It could be worth it to involve the infra team to see how to fail early. Thoughts? > [1] https://review.opendev.org/762637 > > -yoctozepto > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Fri Nov 13 12:54:06 2020 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Fri, 13 Nov 2020 13:54:06 +0100 Subject: [release][masakari] - [Release-job-failures] Release of openstack/masakari-monitors for ref refs/tags/(7.0.1|8.0.2|9.0.1) failed In-Reply-To: References: Message-ID: On Fri, Nov 13, 2020 at 1:46 PM Herve Beraud wrote: > > Le ven. 13 nov. 2020 à 13:17, Radosław Piliszek a écrit : >> >> My question is whether we could detect such issues more proactively? > > Good question... I don't think that this kind of a check should be hosted on the release management side. > Here our issue is more an environment issue, It's due to the fact that we decided to run the job `publish-openstack-artifacts` on ubuntu-focal, so to detect this kind of issue early I think that jobs on the projects side should rely on ubuntu-focal too. I'm not a Zuul expert and I don't know if it is possible to add a condition based on the branches (per example) to choose the right env (focal or not). By following this way I guess it could be possible to fail early on the project side, and it could allow you to fix this kind of issue well before proposing a new release. In other words, if projects's jobs env are aligned with release management our job we could catch them early. The thing is Focal is not a target platform for Train/Ussuri so projects should not just switch to it for their CI. > > We have other scenarios to consider. These are when no patches haven't been merged since a while on projects side, and where a release is proposed, in this case even if environments are aligned, in this case we aren't able to detect this kind of issue, and they will continue to occur during publication, as in this case. In Masakari Monitors' case it was the previous one. The CI was green as long as one didn't move it to Focal. Surely, there will be cases where this particular scenario applies but then it is really up to the project team. > > It could be worth it to involve the infra team to see how to fail early. > Good call, could use their expertise. I shall repost this thread. -yoctozepto From radoslaw.piliszek at gmail.com Fri Nov 13 12:58:18 2020 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Fri, 13 Nov 2020 13:58:18 +0100 Subject: [release][infra] Discrepancy between release jobs and the "normal" jobs CI in terms of distro Message-ID: I did not quote the original subject because it was too long. It was: [release][masakari] - [Release-job-failures] Release of openstack/masakari-monitors for ref refs/tags/(7.0.1|8.0.2|9.0.1) failed Particularly, we are continuing the discussion from: http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018743.html Would it be possible what Hervé is proposing? I.e. better segregation of distro per branch of release? I believe it would be a rare situation but surely testing something on Bionic and trying to release on Focal might have its quirks. -yoctozepto From hberaud at redhat.com Fri Nov 13 13:05:52 2020 From: hberaud at redhat.com (Herve Beraud) Date: Fri, 13 Nov 2020 14:05:52 +0100 Subject: [oslo][release] Oslo's Transition To Independent In-Reply-To: References: <4a9dc3ba-ef77-fdfd-2729-b7cb6357e3ed@nemebean.com> Message-ID: Thanks Julia for your response :) I propose the following migration. Transitioning to independent [1] model: - oslo.i18 - oslo.log - oslo.reports - oslo.upgradecheck - oslotest - osprofiler - stevedore - taskflow - tooz Remaining under the cycle-with-intermediary [2] model: - oslo.concurrency - oslo.config - oslo.context - oslo.db - oslo.limit - oslo.messaging - oslo.middleware - oslo.policy - oslo.privsep - oslo.rootwrap - oslo.serialization - oslo.service - oslo.utils - oslo.versionedobjects - oslo.vmware I'll wait a bit before proposing the migration to allow everybody to react about the proposed lists. Let me know if it makes sense for you and don't hesitate to debate on the proposed migration. [1] https://releases.openstack.org/reference/release_models.html#independent [2] https://releases.openstack.org/reference/release_models.html#cycle-with-intermediary Le lun. 9 nov. 2020 à 17:15, Julia Kreger a écrit : > Top posting because I'm a horrible person. > > Anyway, I think moving oslo to independent makes lots of sense, at > least to me. The key I think is to have the ability to backport and > release a patch/revisin/fix release if there is a major issue, but the > obligation to backport or even set a foundation to do so is a whole > other matter. > > My overall feeling, for something as stable as the oslo libraries, > that cycle-with-intermediacy path may just end up being a frustrating > headache, that is if the team feels confident and actively manages > their own releases of the various libraries. Also, Under the existing > model and policy of the release team, they would basically end up back > where they started if the libraries failed to release multiple times, > which may not make sense for stable libraries. > > Anyway, just my $0.02. > > -Julia > > On Fri, Nov 6, 2020 at 2:04 AM Herve Beraud wrote: > > > > First, thanks for your answer. > > > > Le mer. 4 nov. 2020 à 15:50, Ben Nemec a écrit > : > >> > >> > >> > >> On 11/4/20 7:31 AM, Herve Beraud wrote: > >> > Greetings, > >> > > >> > Is it time for us to move some parts of Oslo to the independent > release > >> > model [1]? > >> > > >> > I think we could consider Oslo world is mostly stable enough to answer > >> > yes to the previous question. > >> > > >> > However, the goal of this email is to trigger the debat and see which > >> > deliverables could be transitioned to the independent model. > >> > > >> > Do we need to expect that major changes will happen within Oslo and > who > >> > could warrant to continue to follow cycle-with-intermediary model [2]? > >> > >> I would hesitate to try to predict the future on what will see major > >> changes and what won't. I would prefer to look at this more from the > >> perspective of what Oslo libraries are tied to the OpenStack version. > >> For example, I don't think oslo.messaging should be moved to > >> independent. It's important that RPC has a sane version to version > >> upgrade path, and the easiest way to ensure that is to keep it on the > >> regular cycle release schedule. The same goes for other libraries too: > >> oslo.versionedobjects, oslo.policy, oslo.service, oslo.db, possibly also > >> things like oslo.config and oslo.context (I suspect contexts need to be > >> release-specific, but maybe someone from a consuming project can weigh > >> in). Even oslo.serialization could have upgrade impacts if it is being > >> used to serialize internal data in a service. > > > > > > Agreed, the goal here isn't to try to move everything to the independent > model but more to identify which projects could be eligible for this switch. > > I strongly agree that the previous list of projects that you quote > should stay binded to openstack cycles and should continue to rely on > stable branches. > > These kinds of projects and also openstack's services are strongly tied > to backends, their version, and available APIs and so to openstack's > series, so they must remain linked to them. > > > >> > >> That said, many of the others can probably be moved. oslo.i18n and > >> oslo.upgradecheck are both pretty stable at this point and not really > >> tied to a specific release. As long as we're responsible with any future > >> changes to them it should be pretty safe to make them independent. > > > > > > Agreed. > > > >> > >> This does raise a question though: Are the benefits of going independent > >> with the release model sufficient to justify splitting the release > >> models of the Oslo projects? I assume the motivation is to avoid having > >> to do as many backports of bug fixes, but if we're mostly doing this > >> with low-volume, stable projects does it gain us that much? > > > > > > Yes, you're right, it could help us to reduce our needed maintenance and > so our Oslo's activity in general. > > Indeed, about 35 projects are hosted by Oslo and concerning the active > maintainers the trend isn't on the rise. > > So reducing the number of stable branches to maintain could benefit us, > and it could be done by moving projects to an independent model. > > > >> > >> > >> I guess I don't have a strong opinion one way or another on this yet, > >> and would defer to our release liaisons if they want to go one way or > >> other other. Hopefully this provides some things to think about though. > > > > > > Yes you provided interesting observations, thanks. > > It could be interesting to get feedback from other cores. > > > >> > >> -Ben > >> > > > > > > -- > > Hervé Beraud > > Senior Software Engineer at Red Hat > > irc: hberaud > > https://github.com/4383/ > > https://twitter.com/4383hberaud > > -----BEGIN PGP SIGNATURE----- > > > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > > v6rDpkeNksZ9fFSyoY2o > > =ECSj > > -----END PGP SIGNATURE----- > > > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaifeng.w at gmail.com Fri Nov 13 13:38:07 2020 From: kaifeng.w at gmail.com (Kaifeng Wang) Date: Fri, 13 Nov 2020 21:38:07 +0800 Subject: Ironic use shellinabox doesn't work In-Reply-To: References: Message-ID: There is nothing wrong with the openstack side according to your context, but you need to double check the BMC configuration and kernel parameters before you can make it work in the dashboard or shellinabox web service. You should have something like "console=ttyS0,115200n8" in the kernel parameters, and the parameters should match what's configured in the BIOS. I'd suggest you to start diagnosing with ipmitool because it's the underlying tool used by ironic, try ipmitool sol activate, if you can't do anything there, you definity can't do anything from socat/shellinabox. On Fri, Nov 13, 2020 at 4:17 PM Ankele zhang wrote: > Hello~ Wang > > Thanks for your email very much, you show me hope. > There are some problems that need your help. > > My Ironic baremetal node's BIOS has enabled the SOL, and I have configure > the baremetal node correctly guided by 'https://docs.openstack.org/rocky' > and the result of the command line 'openstack baremetal node console' is > ok, but the SOL page is still frozen. After that, I changed my > enabled_console_interfaces from ipmitool-shellinabox to ipmitool-socat, and > recreate my baremetal node and recreate my nova server, everything is the > same as before, I got a frozen SOL page in dashboard. > > I don't know why the docs of openstack.org is incomplete, or socat or > shellinabox. Maybe you can give me some advice. > Looking forward to your reply again! > > > Ankele > > Kaifeng Wang 于2020年11月13日周五 上午12:04写道： > >> Hi, >> >> "SOL Session operational" is a BMC prompt, actually you have successfully >> connected to it, before you can interact with the terminal, the Serial >> Redirection (or something called that) needs to be enabled in the BIOS, >> also make sure you have matching baud rate set to the bootloader for the >> tty. >> >> P.S. SOL does not work for Windows systems. >> >> On Thu, Nov 12, 2020 at 11:05 PM Ankele zhang >> wrote: >> >>> Hello~ >>> >>> I have a OpenStack platform( Rocky ) on CentOS7.6, and I installed >>> Ironic components on it. I can manage bare metal node with Ironic and I >>> plan to use shellinabox to manage the bare metal node remotely. >>> I had config conductor ironic.conf: >>> [DEFAULT] >>> ... >>> enabled_console_interfaces = ipmitool-shellinabox,no-console >>> I had config shellinabox: >>> USER=shellinabox >>> GROUP=shellinabox >>> CERTDIR=/var/lib/shellinabox >>> PORT=4200 >>> OPTS="--disable-ssl-menu -s /:LOGIN" >>> My 'openstack baremetal node console show BM01': >>> console_enabled: True and console_info.url: http://192.168.3.84:8023 >>> [image: image.png] >>> Now, I can access https://192.168.3.84:4200 is OK, and I can log >>> in and manage it. >>> But, when I access http://192.168.3.84:8023: >>> [image: image.png] >>> can not type anything into it. >>> >>> Look forward to hearing from you! >>> >>> >>> Ankele >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 9088 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 7799 bytes Desc: not available URL: From owalsh at redhat.com Fri Nov 13 14:19:10 2020 From: owalsh at redhat.com (Oliver Walsh) Date: Fri, 13 Nov 2020 14:19:10 +0000 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: Message-ID: On Fri 13 Nov 2020, 01:25 Takashi Kajinami, wrote: > > For tripleo the first issue to address is in puppet-nova where the dbs > are currently configured for every nova service. > > The fix seems trivial - https://review.opendev.org/755689. I also think > that should be completely safe to backport this to all stable branches. > I don't know whether we can backport that to stable branches. > I agreed to remove nova::db from the base nova class because we already > deprecated database parameters in the nova class, but in stable branches > we have these parameters still valid and removal of nova::db can cause some > issues with these parameters. (I guess pick dosn't work if the nova class > was > defined AFTER nova::db class and there are no hieradata used) > I believe you are correct about the pick function. However I cannot think of any valid use case where the nova class would be used without also using one of the service specific classes (nova::api/nova::compute/nova::scheduler). i.e if you previously did something like this it would still work: class { 'nova': database_connection => "foobar" } include nova::api if you previously did this it didn't work and continues to not work: include nova::api class { 'nova': database_connection => "foobar" } if you previously did this you would get db conf, now you will not: class { 'nova': database_connection => "foobar" } I'm not sure what purpose of this would be. I guess if you want to generate a nova.conf that contains just the config options that are common to all services... If that is the use case then the DB creds should not be included, they are not common to all nova services. If you are still concerned then in the backports we could continue including nova::db when any of the deprecated params are set. > So I'd say it's better to leave it in stable branches if nova doesn't > require > absence of db parameters in stable branches. > > Note that we can remove these parameters from compute nodes in TripleO > deployment > if we completely remove these hieradata from compute nodes. > Compute nodes would be ok but Controllers have nova-compute for ironic. Single-node all-in-one deployments are obviously an issue too. Cheers, Ollie > Also from puppet's perspective we still need some fixes because the > standalone > deployment can still be broken with the change in nova. > We need to know what would be the decision made in each distro packaging > and use the proper config files to store db parameters or the other > parameters. > > > > On Fri, Nov 13, 2020 at 1:43 AM Oliver Walsh wrote: > >> IIUC from Sean's reply most of the heavyweight configuration management >> frameworks already address the security concern. >> >> For tripleo the first issue to address is in puppet-nova where the dbs >> are currently configured for every nova service. The fix seems trivial - >> https://review.opendev.org/755689. I also think that should be >> completely safe to backport this to all stable branches. >> >> The tripleo changes in https://review.opendev.org/#/c/718552/ are not >> strictly necessary to remove the db creds from nova.conf. However I need >> to go further, also removing the hieradata that contains the db creds since >> completely removing the db creds from the compute hosts is the >> ultimate goal here. >> >> So when the configuration management frameworks are all good then what >> are we actually concerned about security-wise? Is it just operators that >> roll their own deployments? >> >> Cheers, >> Ollie >> >> On Wed, 11 Nov 2020 at 16:37, Balázs Gibizer >> wrote: >> >>> Dear packagers and deployment engine developers, >>> >>> Since Icehouse nova-compute service does not need any database >>> configuration as it uses the message bus to access data in the database >>> via the conductor service. Also, the nova configuration guide states >>> that the nova-compute service should not have the >>> [api_database]connection config set. Having any DB credentials >>> configured for the nova-compute is a security risk as well since that >>> service runs close to the hypervisor. Since Rocky[1] nova-compute >>> service fails if you configure API DB credentials and set upgrade_level >>> config to 'auto'. >>> >>> Now we are proposing a patch[2] that makes nova-compute fail at startup >>> if the [database]connection or the [api_database]connection is >>> configured. We know that this breaks at least the rpm packaging, debian >>> packaging, and puppet-nova. The problem there is that in an all-in-on >>> deployment scenario the nova.conf file generated by these tools is >>> shared between all the nova services and therefore nova-compute sees DB >>> credentials. As a counter-example, devstack generates a separate >>> nova-cpu.conf and passes that to the nova-compute service even in an >>> all-in-on setup. >>> >>> The nova team would like to merge [2] during Wallaby but we are OK to >>> delay the patch until Wallaby Milestone 2 so that the packagers and >>> deployment tools can catch up. Please let us know if you are impacted >>> and provide a way to track when you are ready with the modification >>> that allows [2] to be merged. >>> >>> There was a long discussion on #openstack-nova today[3] around this >>> topic. So you can find more detailed reasoning there[3]. >>> >>> Cheers, >>> gibi >>> >>> [1] >>> >>> https://github.com/openstack/nova/blob/dc93e3b510f53d5b2198c8edd22528f0c899617e/nova/compute/rpcapi.py#L441-L457 >>> [2] https://review.opendev.org/#/c/762176 >>> [3] >>> >>> http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2020-11-11.log.html#t2020-11-11T10:51:23 >>> -- >>> >>> http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2020-11-11.log.html#t2020-11-11T14:40:51 >>> >>> >>> >>> > > -- > ---------- > Takashi Kajinami > Senior Software Maintenance Engineer > Customer Experience and Engagement > Red Hat > e-mail: tkajinam at redhat.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juliaashleykreger at gmail.com Fri Nov 13 14:28:50 2020 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Fri, 13 Nov 2020 06:28:50 -0800 Subject: [oslo][release] Oslo's Transition To Independent In-Reply-To: References: <4a9dc3ba-ef77-fdfd-2729-b7cb6357e3ed@nemebean.com> Message-ID: Sounds super reasonable to me! -Julia On Fri, Nov 13, 2020 at 5:07 AM Herve Beraud wrote: > > Thanks Julia for your response :) > > I propose the following migration. > > Transitioning to independent [1] model: > - oslo.i18 > - oslo.log > - oslo.reports > - oslo.upgradecheck > - oslotest > - osprofiler > - stevedore > - taskflow > - tooz > > Remaining under the cycle-with-intermediary [2] model: > - oslo.concurrency > - oslo.config > - oslo.context > - oslo.db > - oslo.limit > - oslo.messaging > - oslo.middleware > - oslo.policy > - oslo.privsep > - oslo.rootwrap > - oslo.serialization > - oslo.service > - oslo.utils > - oslo.versionedobjects > - oslo.vmware > > I'll wait a bit before proposing the migration to allow everybody to react about the proposed lists. > > Let me know if it makes sense for you and don't hesitate to debate on the proposed migration. > > [1] https://releases.openstack.org/reference/release_models.html#independent > [2] https://releases.openstack.org/reference/release_models.html#cycle-with-intermediary > > > Le lun. 9 nov. 2020 à 17:15, Julia Kreger a écrit : >> >> Top posting because I'm a horrible person. >> >> Anyway, I think moving oslo to independent makes lots of sense, at >> least to me. The key I think is to have the ability to backport and >> release a patch/revisin/fix release if there is a major issue, but the >> obligation to backport or even set a foundation to do so is a whole >> other matter. >> >> My overall feeling, for something as stable as the oslo libraries, >> that cycle-with-intermediacy path may just end up being a frustrating >> headache, that is if the team feels confident and actively manages >> their own releases of the various libraries. Also, Under the existing >> model and policy of the release team, they would basically end up back >> where they started if the libraries failed to release multiple times, >> which may not make sense for stable libraries. >> >> Anyway, just my $0.02. >> >> -Julia >> >> On Fri, Nov 6, 2020 at 2:04 AM Herve Beraud wrote: >> > >> > First, thanks for your answer. >> > >> > Le mer. 4 nov. 2020 à 15:50, Ben Nemec a écrit : >> >> >> >> >> >> >> >> On 11/4/20 7:31 AM, Herve Beraud wrote: >> >> > Greetings, >> >> > >> >> > Is it time for us to move some parts of Oslo to the independent release >> >> > model [1]? >> >> > >> >> > I think we could consider Oslo world is mostly stable enough to answer >> >> > yes to the previous question. >> >> > >> >> > However, the goal of this email is to trigger the debat and see which >> >> > deliverables could be transitioned to the independent model. >> >> > >> >> > Do we need to expect that major changes will happen within Oslo and who >> >> > could warrant to continue to follow cycle-with-intermediary model [2]? >> >> >> >> I would hesitate to try to predict the future on what will see major >> >> changes and what won't. I would prefer to look at this more from the >> >> perspective of what Oslo libraries are tied to the OpenStack version. >> >> For example, I don't think oslo.messaging should be moved to >> >> independent. It's important that RPC has a sane version to version >> >> upgrade path, and the easiest way to ensure that is to keep it on the >> >> regular cycle release schedule. The same goes for other libraries too: >> >> oslo.versionedobjects, oslo.policy, oslo.service, oslo.db, possibly also >> >> things like oslo.config and oslo.context (I suspect contexts need to be >> >> release-specific, but maybe someone from a consuming project can weigh >> >> in). Even oslo.serialization could have upgrade impacts if it is being >> >> used to serialize internal data in a service. >> > >> > >> > Agreed, the goal here isn't to try to move everything to the independent model but more to identify which projects could be eligible for this switch. >> > I strongly agree that the previous list of projects that you quote should stay binded to openstack cycles and should continue to rely on stable branches. >> > These kinds of projects and also openstack's services are strongly tied to backends, their version, and available APIs and so to openstack's series, so they must remain linked to them. >> > >> >> >> >> That said, many of the others can probably be moved. oslo.i18n and >> >> oslo.upgradecheck are both pretty stable at this point and not really >> >> tied to a specific release. As long as we're responsible with any future >> >> changes to them it should be pretty safe to make them independent. >> > >> > >> > Agreed. >> > >> >> >> >> This does raise a question though: Are the benefits of going independent >> >> with the release model sufficient to justify splitting the release >> >> models of the Oslo projects? I assume the motivation is to avoid having >> >> to do as many backports of bug fixes, but if we're mostly doing this >> >> with low-volume, stable projects does it gain us that much? >> > >> > >> > Yes, you're right, it could help us to reduce our needed maintenance and so our Oslo's activity in general. >> > Indeed, about 35 projects are hosted by Oslo and concerning the active maintainers the trend isn't on the rise. >> > So reducing the number of stable branches to maintain could benefit us, and it could be done by moving projects to an independent model. >> > >> >> >> >> >> >> I guess I don't have a strong opinion one way or another on this yet, >> >> and would defer to our release liaisons if they want to go one way or >> >> other other. Hopefully this provides some things to think about though. >> > >> > >> > Yes you provided interesting observations, thanks. >> > It could be interesting to get feedback from other cores. >> > >> >> >> >> -Ben >> >> >> > >> > >> > -- >> > Hervé Beraud >> > Senior Software Engineer at Red Hat >> > irc: hberaud >> > https://github.com/4383/ >> > https://twitter.com/4383hberaud >> > -----BEGIN PGP SIGNATURE----- >> > >> > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ >> > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ >> > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP >> > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G >> > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g >> > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw >> > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ >> > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 >> > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y >> > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 >> > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O >> > v6rDpkeNksZ9fFSyoY2o >> > =ECSj >> > -----END PGP SIGNATURE----- >> > >> > > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > From gmann at ghanshyammann.com Fri Nov 13 15:04:50 2020 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 13 Nov 2020 09:04:50 -0600 Subject: [release][masakari] - [Release-job-failures] Release of openstack/masakari-monitors for ref refs/tags/(7.0.1|8.0.2|9.0.1) failed In-Reply-To: References: Message-ID: <175c2233af9.b29635e9169357.6116747736664219007@ghanshyammann.com> ---- On Fri, 13 Nov 2020 06:45:54 -0600 Herve Beraud wrote ---- > > > Le ven. 13 nov. 2020 à 13:17, Radosław Piliszek a écrit : > On Fri, Nov 13, 2020 at 12:09 PM Herve Beraud wrote: > > > > Thanks for the heads up. > > > > Notice that I just submitted a series of patches [1] to fix all masakari's stable branches, feel free to abandon these patches if they aren't needed anymore. > > > > [1] https://review.opendev.org/#/q/topic:fix-libvirt-focal+(status:open+OR+status:merged) > > > > Ah, sorry, did not notice that. > I just went with [1] removing the pkg to avoid the naming issue altogether. > > No problem > > My question is whether we could detect such issues more proactively? > > Good question... I don't think that this kind of a check should be hosted on the release management side.Here our issue is more an environment issue, It's due to the fact that we decided to run the job `publish-openstack-artifacts` on ubuntu-focal, so to detect this kind of issue early I think that jobs on the projects side should rely on ubuntu-focal too. I'm not a Zuul expert and I don't know if it is possible to add a condition based on the branches (per example) to choose the right env (focal or not). By following this way I guess it could be possible to fail early on the project side, and it could allow you to fix this kind of issue well before proposing a new release. In other words, if projects's jobs env are aligned with release management our job we could catch them early. `publish-openstack-artifacts` job should not run for Focal for the stable gate and running it on Focal from Victoria onwards (like all other common jobs). -gmann > We have other scenarios to consider. These are when no patches haven't been merged since a while on projects side, and where a release is proposed, in this case even if environments are aligned, in this case we aren't able to detect this kind of issue, and they will continue to occur during publication, as in this case. > It could be worth it to involve the infra team to see how to fail early. > Thoughts? > > > [1] https://review.opendev.org/762637 > > -yoctozepto > > > > -- > Hervé BeraudSenior Software Engineer at Red Hatirc: hberaudhttps://github.com/4383/https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > > From openstack at nemebean.com Fri Nov 13 15:29:37 2020 From: openstack at nemebean.com (Ben Nemec) Date: Fri, 13 Nov 2020 09:29:37 -0600 Subject: [oslo][release] Oslo's Transition To Independent In-Reply-To: References: <4a9dc3ba-ef77-fdfd-2729-b7cb6357e3ed@nemebean.com> Message-ID: <86f35998-1d6e-85b1-5c3b-e25e45cdd37f@nemebean.com> On 11/13/20 7:05 AM, Herve Beraud wrote: > Thanks Julia for your response :) > > I propose the following migration. > > Transitioning to independent [1] model: > - oslo.i18 > - oslo.log > - oslo.reports > - oslo.upgradecheck > - oslotest > - osprofiler > - stevedore > - taskflow > - tooz These all sound good to me. Honestly, anything that's not oslo.* probably should be on an independent release model since they're explicitly intended for use outside of OpenStack. > > Remaining under the cycle-with-intermediary [2] model: > - oslo.concurrency This doesn't seem particularly tied to a release. Is there a reason it should stay on the cycle release schedule? > - oslo.config > - oslo.context > - oslo.db > - oslo.limit > - oslo.messaging > - oslo.middleware > - oslo.policy > - oslo.privsep > - oslo.rootwrap Given that rootwrap is essentially in maintenance mode and will hopefully not be used once we complete the privsep community goal, I feel like this one could go independent too. > - oslo.serialization > - oslo.service > - oslo.utils > - oslo.versionedobjects > - oslo.vmware > > I'll wait a bit before proposing the migration to allow everybody to > react about the proposed lists. > > Let me know if it makes sense for you and don't hesitate to debate on > the proposed migration. The proposed changes lgtm. I think we could move a couple more as discussed above, but I'm good with it either way. > > [1] https://releases.openstack.org/reference/release_models.html#independent > [2] > https://releases.openstack.org/reference/release_models.html#cycle-with-intermediary > > > Le lun. 9 nov. 2020 à 17:15, Julia Kreger > a écrit : > > Top posting because I'm a horrible person. > > Anyway, I think moving oslo to independent makes lots of sense, at > least to me. The key I think is to have the ability to backport and > release a patch/revisin/fix release if there is a major issue, but the > obligation to backport or even set a foundation to do so is a whole > other matter. > > My overall feeling, for something as stable as the oslo libraries, > that cycle-with-intermediacy path may just end up being a frustrating > headache, that is if the team feels confident and actively manages > their own releases of the various libraries. Also, Under the existing > model and policy of the release team, they would basically end up back > where they started if the libraries failed to release multiple times, > which may not make sense for stable libraries. > > Anyway, just my $0.02. > > -Julia > > On Fri, Nov 6, 2020 at 2:04 AM Herve Beraud > wrote: > > > > First, thanks for your answer. > > > > Le mer. 4 nov. 2020 à 15:50, Ben Nemec > a écrit : > >> > >> > >> > >> On 11/4/20 7:31 AM, Herve Beraud wrote: > >> > Greetings, > >> > > >> > Is it time for us to move some parts of Oslo to the > independent release > >> > model [1]? > >> > > >> > I think we could consider Oslo world is mostly stable enough > to answer > >> > yes to the previous question. > >> > > >> > However, the goal of this email is to trigger the debat and > see which > >> > deliverables could be transitioned to the independent model. > >> > > >> > Do we need to expect that major changes will happen within > Oslo and who > >> > could warrant to continue to follow cycle-with-intermediary > model [2]? > >> > >> I would hesitate to try to predict the future on what will see major > >> changes and what won't. I would prefer to look at this more from the > >> perspective of what Oslo libraries are tied to the OpenStack > version. > >> For example, I don't think oslo.messaging should be moved to > >> independent. It's important that RPC has a sane version to version > >> upgrade path, and the easiest way to ensure that is to keep it > on the > >> regular cycle release schedule. The same goes for other > libraries too: > >> oslo.versionedobjects, oslo.policy, oslo.service, oslo.db, > possibly also > >> things like oslo.config and oslo.context (I suspect contexts > need to be > >> release-specific, but maybe someone from a consuming project can > weigh > >> in). Even oslo.serialization could have upgrade impacts if it is > being > >> used to serialize internal data in a service. > > > > > > Agreed, the goal here isn't to try to move everything to the > independent model but more to identify which projects could be > eligible for this switch. > > I strongly agree that the previous list of projects that you > quote should stay binded to openstack cycles and should continue to > rely on stable branches. > > These kinds of projects and also openstack's services are > strongly tied to backends, their version, and available APIs and so > to openstack's series, so they must remain linked to them. > > > >> > >> That said, many of the others can probably be moved. oslo.i18n and > >> oslo.upgradecheck are both pretty stable at this point and not > really > >> tied to a specific release. As long as we're responsible with > any future > >> changes to them it should be pretty safe to make them independent. > > > > > > Agreed. > > > >> > >> This does raise a question though: Are the benefits of going > independent > >> with the release model sufficient to justify splitting the release > >> models of the Oslo projects? I assume the motivation is to avoid > having > >> to do as many backports of bug fixes, but if we're mostly doing this > >> with low-volume, stable projects does it gain us that much? > > > > > > Yes, you're right, it could help us to reduce our needed > maintenance and so our Oslo's activity in general. > > Indeed, about 35 projects are hosted by Oslo and concerning the > active maintainers the trend isn't on the rise. > > So reducing the number of stable branches to maintain could > benefit us, and it could be done by moving projects to an > independent model. > > > >> > >> > >> I guess I don't have a strong opinion one way or another on this > yet, > >> and would defer to our release liaisons if they want to go one > way or > >> other other. Hopefully this provides some things to think about > though. > > > > > > Yes you provided interesting observations, thanks. > > It could be interesting to get feedback from other cores. > > > >> > >> -Ben > >> > > > > > > -- > > Hervé Beraud > > Senior Software Engineer at Red Hat > > irc: hberaud > > https://github.com/4383/ > > https://twitter.com/4383hberaud > > -----BEGIN PGP SIGNATURE----- > > > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > > v6rDpkeNksZ9fFSyoY2o > > =ECSj > > -----END PGP SIGNATURE----- > > > > > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > From hberaud at redhat.com Fri Nov 13 15:55:57 2020 From: hberaud at redhat.com (Herve Beraud) Date: Fri, 13 Nov 2020 16:55:57 +0100 Subject: [release][masakari] - [Release-job-failures] Release of openstack/masakari-monitors for ref refs/tags/(7.0.1|8.0.2|9.0.1) failed In-Reply-To: <175c2233af9.b29635e9169357.6116747736664219007@ghanshyammann.com> References: <175c2233af9.b29635e9169357.6116747736664219007@ghanshyammann.com> Message-ID: Notice that this patch will face the same error too https://review.opendev.org/#/c/762402/2 I'm going to hold this one until a fix is merged on the project side. Don't forget to update the sha when the issue is fixed. Le ven. 13 nov. 2020 à 16:04, Ghanshyam Mann a écrit : > ---- On Fri, 13 Nov 2020 06:45:54 -0600 Herve Beraud > wrote ---- > > > > > > Le ven. 13 nov. 2020 à 13:17, Radosław Piliszek < > radoslaw.piliszek at gmail.com> a écrit : > > On Fri, Nov 13, 2020 at 12:09 PM Herve Beraud > wrote: > > > > > > Thanks for the heads up. > > > > > > Notice that I just submitted a series of patches [1] to fix all > masakari's stable branches, feel free to abandon these patches if they > aren't needed anymore. > > > > > > [1] > https://review.opendev.org/#/q/topic:fix-libvirt-focal+(status:open+OR+status:merged) > > > > > > > Ah, sorry, did not notice that. > > I just went with [1] removing the pkg to avoid the naming issue > altogether. > > > > No problem > > > > My question is whether we could detect such issues more proactively? > > > > Good question... I don't think that this kind of a check should be > hosted on the release management side.Here our issue is more an environment > issue, It's due to the fact that we decided to run the job > `publish-openstack-artifacts` on ubuntu-focal, so to detect this kind of > issue early I think that jobs on the projects side should rely on > ubuntu-focal too. I'm not a Zuul expert and I don't know if it is possible > to add a condition based on the branches (per example) to choose the right > env (focal or not). By following this way I guess it could be possible to > fail early on the project side, and it could allow you to fix this kind of > issue well before proposing a new release. In other words, if projects's > jobs env are aligned with release management our job we could catch them > early. > > `publish-openstack-artifacts` job should not run for Focal for the stable > gate and running it on Focal from Victoria onwards (like all other common > jobs). > > -gmann > > > > We have other scenarios to consider. These are when no patches haven't > been merged since a while on projects side, and where a release is > proposed, in this case even if environments are aligned, in this case we > aren't able to detect this kind of issue, and they will continue to occur > during publication, as in this case. > > It could be worth it to involve the infra team to see how to fail early. > > Thoughts? > > > > > > [1] https://review.opendev.org/762637 > > > > -yoctozepto > > > > > > > > -- > > Hervé BeraudSenior Software Engineer at Red Hatirc: hberaudhttps:// > github.com/4383/https://twitter.com/4383hberaud > > -----BEGIN PGP SIGNATURE----- > > > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > > v6rDpkeNksZ9fFSyoY2o > > =ECSj > > -----END PGP SIGNATURE----- > > > > > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From owalsh at redhat.com Fri Nov 13 16:18:30 2020 From: owalsh at redhat.com (Oliver Walsh) Date: Fri, 13 Nov 2020 16:18:30 +0000 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: <12CQJQ.RNX7AJ4TRBJ21@est.tech> References: <864396842.58157343.1605179360197.JavaMail.zimbra@redhat.com> <12CQJQ.RNX7AJ4TRBJ21@est.tech> Message-ID: On Fri, 13 Nov 2020 at 10:06, Balázs Gibizer wrote: > > > On Thu, Nov 12, 2020 at 06:09, Javier Pena wrote: > >> On 11/11/20 5:35 PM, Balázs Gibizer wrote: > >> > Dear packagers and deployment engine developers, > >> > > >> > Since Icehouse nova-compute service does not need any database > >> > configuration as it uses the message bus to access data in the > >> database > >> > via the conductor service. Also, the nova configuration guide > >> states > >> > that the nova-compute service should not have the > >> > [api_database]connection config set. Having any DB credentials > >> > configured for the nova-compute is a security risk as well since > >> that > >> > service runs close to the hypervisor. Since Rocky[1] nova-compute > >> > service fails if you configure API DB credentials and set > >> upgrade_level > >> > config to 'auto'. > >> > > >> > Now we are proposing a patch[2] that makes nova-compute fail at > >> startup > >> > if the [database]connection or the [api_database]connection is > >> > configured. We know that this breaks at least the rpm packaging, > >> debian > >> > packaging, and puppet-nova. The problem there is that in an > >> all-in-on > >> > deployment scenario the nova.conf file generated by these tools is > >> > shared between all the nova services and therefore nova-compute > >> sees DB > >> > credentials. As a counter-example, devstack generates a separate > >> > nova-cpu.conf and passes that to the nova-compute service even in > >> an > >> > all-in-on setup. > >> > > >> > The nova team would like to merge [2] during Wallaby but we are > >> OK to > >> > delay the patch until Wallaby Milestone 2 so that the packagers > >> and > >> > deployment tools can catch up. Please let us know if you are > >> impacted > >> > and provide a way to track when you are ready with the > >> modification that > >> > allows [2] to be merged. > >> > > >> > There was a long discussion on #openstack-nova today[3] around > >> this > >> > topic. So you can find more detailed reasoning there[3]. > >> > > >> > Cheers, > >> > gibi > >> > >> IMO, that's ok if, and only if, we all agree on how to implement it. > >> Best would be if we (all downstream distro + config management) > >> agree on > >> how to implement this. > >> > >> How about, we all implement a /etc/nova/nova-db.conf, and get all > >> services that need db access to use it (ie: starting them with > >> --config-file=/etc/nova/nova-db.conf)? > >> > > > > Hi, > > > > This is going to be an issue for those services we run as a WSGI app. > > Looking at [1], I see > > the app has a hardcoded list of config files to read (api-paste.ini > > and nova.conf), so we'd > > need to modify it at the installer level. > > > > Personally, I like the nova-db.conf way, since it looks like it > > reduces the amount of work > > required for all-in-one installers to adapt, but that requires some > > code change. Would the > > Nova team be happy with adding a nova-db.conf file to that list? > > Devstack solves the all-in-one case by using these config files: > > * nova.conf and api_paste.ini for the wsgi apps e.g. nova-api and > nova-metadata-api * nova.conf for the nova-scheduler and the top level nova-conductor > (super conductor) > * nova-cell.conf for the cell level nova-conductor and the > proxy services, e.g. nova-novncproxy * nova-cpu.conf for the nova-compute service > IIUC for nova-metadata-api "it depends": local_metadata_per_cell=True it needs nova-cell.conf local_metadata_per_cell=False it needs nova.conf Cheers, Ollie > > The nova team suggest to use a similar strategy to separate files. So at the moment we are not planning to change what config files the wsgi > apps will read. > > Cheers, > gibi > > > > > > Regards, > > Javier > > > > > > [1] - > > > https://opendev.org/openstack/nova/src/branch/master/nova/api/openstack/wsgi_app.py#L30 > > > >> If I understand well, these services would need access to db: > >> - conductor > >> - scheduler > >> - novncproxy > >> - serialproxy > >> - spicehtml5proxy > >> - api > >> - api-metadata > >> > >> Is this list correct? Or is there some services that also don't > >> need it? > >> > >> Cheers, > >> > >> Thomas Goirand (zigo) > >> > >> > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cboylan at sapwetik.org Fri Nov 13 16:40:38 2020 From: cboylan at sapwetik.org (Clark Boylan) Date: Fri, 13 Nov 2020 08:40:38 -0800 Subject: =?UTF-8?Q?Re:_[release][infra]_Discrepancy_between_release_jobs_and_the_?= =?UTF-8?Q?"normal"_jobs_CI_in_terms_of_distro?= In-Reply-To: References: Message-ID: <808e3944-38e7-473e-9db9-037332db7dcf@www.fastmail.com> On Fri, Nov 13, 2020, at 4:58 AM, Radosław Piliszek wrote: > I did not quote the original subject because it was too long. > It was: [release][masakari] - [Release-job-failures] Release of > openstack/masakari-monitors for ref refs/tags/(7.0.1|8.0.2|9.0.1) > failed > > Particularly, we are continuing the discussion from: > http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018743.html > > Would it be possible what Hervé is proposing? I.e. better segregation > of distro per branch of release? > I believe it would be a rare situation but surely testing something on > Bionic and trying to release on Focal might have its quirks. The underlying issue is that git tags (what we use to specify a release state) don't map 1:1 to git branches (where we specify zuul job config). For a long time this essentially meant that if you tried to apply branch specific job matcher rules to jobs that ran in a refs/tags/* context those jobs were just skipped. More recently Zuul has made changes to do its best to map a tag state to a branch and load configs from that branch value. The behavior if multiple branches match should be considered though: "If a tag item is enqueued, we look up the branches which contain the commit referenced by the tag. If any of those branches match a branch matcher, the matcher is considered to have matched." [0]. Long story short this was not possible for a long time but is now possible if you are careful. This means the jobs can be updated to have different behaviors based on branches and the tags will be matched to branches. Separately keep in mind that the jobs were moved from bionic to focal to address problems with markdown [1]. It is possible that by moving some branches back to bionic that the jobs will break there. [0] https://zuul-ci.org/docs/zuul/reference/job_def.html#attr-job.branches [1] https://review.opendev.org/#/c/761776/ From rfolco at redhat.com Fri Nov 13 17:07:13 2020 From: rfolco at redhat.com (Rafael Folco) Date: Fri, 13 Nov 2020 15:07:13 -0200 Subject: [tripleo] TripleO CI Summary: Unified Sprint 35 Message-ID: Greetings, The TripleO CI team has just completed **Unified Sprint 35** (Oct 23 thru Nov 12). The following is a summary of completed work during this sprint cycle: In the last sprint we had two major goals: #1 OpenStack Victoria release branching (upstream jobs) and #2 Docker.io removal from upstream CI #1 OpenStack Victoria release branching (upstream jobs) Upstream jobs have been branched for stable/victoria release. Jobs from stable/rocky and stable/stein branches have been deprecated. #2 Docker.io removal from upstream CI Stable branch and CentOS7 jobs have also been converted to content providers. Content provider jobs have been wired-up in more repositories such as puppet-* projects. There are still changes in-flight to be merged, which are expected to happen in the next couple weeks. Content provider changes (160+): https://review.opendev.org/#/q/topic:new-ci-job Upstream promotions [1] Ruck/Rover recorded notes [2]. NEXT SPRINT =========== The planned work for the next sprint is to close-out the content provider work started in the previous sprint, and work on unfinished items for CI related on-going projects: - Elastic recheck / openstack health - Dependency pipeline design and PoC - Job footprint reduction - Cockpit improvements - Quay registry experimentation - Tempest improvements - RPM diff tooling - Reproducer enhancements - Documentation - TripleO core projects - Ansible-role-collect-logs - Upgrade/component pipeline standalone job - Improve container builds The Ruck and Rover shifts for the upcoming weeks are scheduled as follows: Nov 16: Marios Andreou (marios), Ronelle Landy (rlandy) Nov 23: Rafael Folco (rfolco), Arx Cruz (arxcruz) Nov 30: Wesley Hayutin (weshay), Pooja Jadhav (pojadhav) Dec 7: Sorin Sbarnea (zbr), Marios Andreou (marios) Dec 14: Chandan Kumar (chandankumar), Amol Kahat (akahat) Dec 21: Bhagyashri Shewale (bhagyashris), Soniya Vyas (soniya29) Dec 28: Sandeep Yadav (ysandeep), Sagi Shnaidman (sshnaidm) Jan 4: Wesley Hayutin (weshay), Poja Jadhav (pojadhav) Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. Ruck/rover notes to be tracked in hackmd [3]. Thanks, --rfolco [1] http://dashboard-ci.tripleo.org/d/HkOLImOMk/upstream-and-rdo-promotions?orgId=1&fullscreen&panelId=33 [2] https://hackmd.io/a_PhAlijTr-KTWHzGuf3qQ [3] https://hackmd.io/R0kCgz_7SHSix_cNgoC9pg -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Fri Nov 13 17:20:44 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 13 Nov 2020 17:20:44 +0000 Subject: [release][infra] Discrepancy between release jobs and the "normal" jobs CI in terms of distro In-Reply-To: References: Message-ID: <20201113172044.c6cgt7rdy6m6mkeu@yuggoth.org> On 2020-11-13 13:58:18 +0100 (+0100), Radosław Piliszek wrote: [...] > I believe it would be a rare situation but surely testing something on > Bionic and trying to release on Focal might have its quirks. Honestly, I think the real problem here is that we have a bunch of unnecessary cruft in the release-openstack-python job held over from when we used to use tox to create release artifacts. If you look through the log of a successful build you'll see that we're not actually running tox or installing the projects being released, but we're using the ensure-tox and bindep roles anyway. We may not even need ensure-pip in there. The important bits of the job are that it checks out the correct state of the repository and then runs `python3 setup.py sdist bdist_wheel` and then pulls the resulting files back to the executor to be published. That should be fairly consistent no matter what project is being built and no matter what distro it's being built on. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From pramchan at yahoo.com Fri Nov 13 17:21:06 2020 From: pramchan at yahoo.com (prakash RAMCHANDRAN) Date: Fri, 13 Nov 2020 17:21:06 +0000 (UTC) Subject: [OpenStack][InteropWG] Weekly Interop meeting Agenda for Victoria Interop Guidelines in next hr References: <435519786.5170730.1605288066630.ref@mail.yahoo.com> Message-ID: <435519786.5170730.1605288066630@mail.yahoo.com> Hi all, Please join me in next hour weekly Interop WG meetingInterop Working Group - Weekly Friday 10-11 AM  PST Link: https://meetpad.opendev.org/Interop-WG-weekly-meetin Agenda: 1. Interop Guidelines for 2020.10.json 2. Interop add-on Guidelines  for existing2.a  DNS (Designate) 2.b  Orchestration(Heat)3. Interop add-on guidelines for new proposals3.a  FileSystem (Manila)3.b Metal as a Service (Ironic)4. What's next for Interop 2021 with containers & Kubernetes/magnum ? - Need Volunteers with go skills for new conformance test proposals ThanksPrakashFor Interop WGOpenDev Etherpad | | | | OpenDev Etherpad | | | -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Fri Nov 13 18:18:05 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 13 Nov 2020 18:18:05 +0000 Subject: [release][infra] Discrepancy between release jobs and the "normal" jobs CI in terms of distro In-Reply-To: <20201113172044.c6cgt7rdy6m6mkeu@yuggoth.org> References: <20201113172044.c6cgt7rdy6m6mkeu@yuggoth.org> Message-ID: <20201113181805.wwwlhkqxalbrrbxz@yuggoth.org> On 2020-11-13 17:20:44 +0000 (+0000), Jeremy Stanley wrote: [...] > Honestly, I think the real problem here is that we have a bunch of > unnecessary cruft in the release-openstack-python job held over > from when we used to use tox to create release artifacts. If you > look through the log of a successful build you'll see that we're > not actually running tox or installing the projects being > released, but we're using the ensure-tox and bindep roles anyway. [...] This solution has been proposed: https://review.opendev.org/762699 -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From owalsh at redhat.com Fri Nov 13 19:02:14 2020 From: owalsh at redhat.com (Oliver Walsh) Date: Fri, 13 Nov 2020 19:02:14 +0000 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: <864396842.58157343.1605179360197.JavaMail.zimbra@redhat.com> <12CQJQ.RNX7AJ4TRBJ21@est.tech> Message-ID: On Fri 13 Nov 2020, 16:18 Oliver Walsh, wrote: > > > On Fri, 13 Nov 2020 at 10:06, Balázs Gibizer > wrote: > >> >> >> On Thu, Nov 12, 2020 at 06:09, Javier Pena wrote: >> >> On 11/11/20 5:35 PM, Balázs Gibizer wrote: >> >> > Dear packagers and deployment engine developers, >> >> > >> >> > Since Icehouse nova-compute service does not need any database >> >> > configuration as it uses the message bus to access data in the >> >> database >> >> > via the conductor service. Also, the nova configuration guide >> >> states >> >> > that the nova-compute service should not have the >> >> > [api_database]connection config set. Having any DB credentials >> >> > configured for the nova-compute is a security risk as well since >> >> that >> >> > service runs close to the hypervisor. Since Rocky[1] nova-compute >> >> > service fails if you configure API DB credentials and set >> >> upgrade_level >> >> > config to 'auto'. >> >> > >> >> > Now we are proposing a patch[2] that makes nova-compute fail at >> >> startup >> >> > if the [database]connection or the [api_database]connection is >> >> > configured. We know that this breaks at least the rpm packaging, >> >> debian >> >> > packaging, and puppet-nova. The problem there is that in an >> >> all-in-on >> >> > deployment scenario the nova.conf file generated by these tools is >> >> > shared between all the nova services and therefore nova-compute >> >> sees DB >> >> > credentials. As a counter-example, devstack generates a separate >> >> > nova-cpu.conf and passes that to the nova-compute service even in >> >> an >> >> > all-in-on setup. >> >> > >> >> > The nova team would like to merge [2] during Wallaby but we are >> >> OK to >> >> > delay the patch until Wallaby Milestone 2 so that the packagers >> >> and >> >> > deployment tools can catch up. Please let us know if you are >> >> impacted >> >> > and provide a way to track when you are ready with the >> >> modification that >> >> > allows [2] to be merged. >> >> > >> >> > There was a long discussion on #openstack-nova today[3] around >> >> this >> >> > topic. So you can find more detailed reasoning there[3]. >> >> > >> >> > Cheers, >> >> > gibi >> >> >> >> IMO, that's ok if, and only if, we all agree on how to implement it. >> >> Best would be if we (all downstream distro + config management) >> >> agree on >> >> how to implement this. >> >> >> >> How about, we all implement a /etc/nova/nova-db.conf, and get all >> >> services that need db access to use it (ie: starting them with >> >> --config-file=/etc/nova/nova-db.conf)? >> >> >> > >> > Hi, >> > >> > This is going to be an issue for those services we run as a WSGI app. >> > Looking at [1], I see >> > the app has a hardcoded list of config files to read (api-paste.ini >> > and nova.conf), so we'd >> > need to modify it at the installer level. >> > >> > Personally, I like the nova-db.conf way, since it looks like it >> > reduces the amount of work >> > required for all-in-one installers to adapt, but that requires some >> > code change. Would the >> > Nova team be happy with adding a nova-db.conf file to that list? >> >> Devstack solves the all-in-one case by using these config files: >> >> * nova.conf and api_paste.ini for the wsgi apps e.g. nova-api and >> nova-metadata-api > > * nova.conf for the nova-scheduler and the top level nova-conductor >> (super conductor) >> * nova-cell.conf for the cell level nova-conductor and the >> proxy services, e.g. nova-novncproxy > > * nova-cpu.conf for the nova-compute service >> > > IIUC for nova-metadata-api "it depends": > local_metadata_per_cell=True it needs nova-cell.conf > local_metadata_per_cell=False it needs nova.conf > > Cheers, > Ollie > Also Sean and Dan mentioned the other day that the cell level nova-conductor requires api db access, which I really did not expect. Cheers, Ollie > >> >> The nova team suggest to use a similar strategy to separate files. So > > at the moment we are not planning to change what config files the wsgi >> apps will read. >> >> Cheers, >> gibi >> >> >> > >> > Regards, >> > Javier >> > >> > >> > [1] - >> > >> https://opendev.org/openstack/nova/src/branch/master/nova/api/openstack/wsgi_app.py#L30 >> > >> >> If I understand well, these services would need access to db: >> >> - conductor >> >> - scheduler >> >> - novncproxy >> >> - serialproxy >> >> - spicehtml5proxy >> >> - api >> >> - api-metadata >> >> >> >> Is this list correct? Or is there some services that also don't >> >> need it? >> >> >> >> Cheers, >> >> >> >> Thomas Goirand (zigo) >> >> >> >> >> > >> > >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From owalsh at redhat.com Fri Nov 13 19:59:54 2020 From: owalsh at redhat.com (Oliver Walsh) Date: Fri, 13 Nov 2020 19:59:54 +0000 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: <864396842.58157343.1605179360197.JavaMail.zimbra@redhat.com> <12CQJQ.RNX7AJ4TRBJ21@est.tech> Message-ID: On Fri 13 Nov 2020, 16:18 Oliver Walsh, wrote: > > > On Fri, 13 Nov 2020 at 10:06, Balázs Gibizer > wrote: > >> >> >> On Thu, Nov 12, 2020 at 06:09, Javier Pena wrote: >> >> On 11/11/20 5:35 PM, Balázs Gibizer wrote: >> >> > Dear packagers and deployment engine developers, >> >> > >> >> > Since Icehouse nova-compute service does not need any database >> >> > configuration as it uses the message bus to access data in the >> >> database >> >> > via the conductor service. Also, the nova configuration guide >> >> states >> >> > that the nova-compute service should not have the >> >> > [api_database]connection config set. Having any DB credentials >> >> > configured for the nova-compute is a security risk as well since >> >> that >> >> > service runs close to the hypervisor. Since Rocky[1] nova-compute >> >> > service fails if you configure API DB credentials and set >> >> upgrade_level >> >> > config to 'auto'. >> >> > >> >> > Now we are proposing a patch[2] that makes nova-compute fail at >> >> startup >> >> > if the [database]connection or the [api_database]connection is >> >> > configured. We know that this breaks at least the rpm packaging, >> >> debian >> >> > packaging, and puppet-nova. The problem there is that in an >> >> all-in-on >> >> > deployment scenario the nova.conf file generated by these tools is >> >> > shared between all the nova services and therefore nova-compute >> >> sees DB >> >> > credentials. As a counter-example, devstack generates a separate >> >> > nova-cpu.conf and passes that to the nova-compute service even in >> >> an >> >> > all-in-on setup. >> >> > >> >> > The nova team would like to merge [2] during Wallaby but we are >> >> OK to >> >> > delay the patch until Wallaby Milestone 2 so that the packagers >> >> and >> >> > deployment tools can catch up. Please let us know if you are >> >> impacted >> >> > and provide a way to track when you are ready with the >> >> modification that >> >> > allows [2] to be merged. >> >> > >> >> > There was a long discussion on #openstack-nova today[3] around >> >> this >> >> > topic. So you can find more detailed reasoning there[3]. >> >> > >> >> > Cheers, >> >> > gibi >> >> >> >> IMO, that's ok if, and only if, we all agree on how to implement it. >> >> Best would be if we (all downstream distro + config management) >> >> agree on >> >> how to implement this. >> >> >> >> How about, we all implement a /etc/nova/nova-db.conf, and get all >> >> services that need db access to use it (ie: starting them with >> >> --config-file=/etc/nova/nova-db.conf)? >> >> >> > >> > Hi, >> > >> > This is going to be an issue for those services we run as a WSGI app. >> > Looking at [1], I see >> > the app has a hardcoded list of config files to read (api-paste.ini >> > and nova.conf), so we'd >> > need to modify it at the installer level. >> > >> > Personally, I like the nova-db.conf way, since it looks like it >> > reduces the amount of work >> > required for all-in-one installers to adapt, but that requires some >> > code change. Would the >> > Nova team be happy with adding a nova-db.conf file to that list? >> >> Devstack solves the all-in-one case by using these config files: >> >> * nova.conf and api_paste.ini for the wsgi apps e.g. nova-api and >> nova-metadata-api > > * nova.conf for the nova-scheduler and the top level nova-conductor >> (super conductor) >> * nova-cell.conf for the cell level nova-conductor and the >> proxy services, e.g. nova-novncproxy > > * nova-cpu.conf for the nova-compute service >> > > IIUC for nova-metadata-api "it depends": > local_metadata_per_cell=True it needs nova-cell.conf > But hang on a second... metadata-api is a wsgi app, which hardcodes 'nova.conf', so how can this work in devstack? local_metadata_per_cell=False it needs nova.conf > > Cheers, > Ollie > > >> >> The nova team suggest to use a similar strategy to separate files. So > > at the moment we are not planning to change what config files the wsgi >> apps will read. >> >> Cheers, >> gibi >> >> >> > >> > Regards, >> > Javier >> > >> > >> > [1] - >> > >> https://opendev.org/openstack/nova/src/branch/master/nova/api/openstack/wsgi_app.py#L30 >> > >> >> If I understand well, these services would need access to db: >> >> - conductor >> >> - scheduler >> >> - novncproxy >> >> - serialproxy >> >> - spicehtml5proxy >> >> - api >> >> - api-metadata >> >> >> >> Is this list correct? Or is there some services that also don't >> >> need it? >> >> >> >> Cheers, >> >> >> >> Thomas Goirand (zigo) >> >> >> >> >> > >> > >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pramchan at yahoo.com Fri Nov 13 20:03:07 2020 From: pramchan at yahoo.com (prakash RAMCHANDRAN) Date: Fri, 13 Nov 2020 20:03:07 +0000 (UTC) Subject: [Openstack][InteropWG] Victoria Interop Guidelines Patch and Future Directions In-Reply-To: References: Message-ID: <1138014553.5255396.1605297787698@mail.yahoo.com> Hi all, We are in-midst of transition from OSF to OIF and hence decided,  not  to add more add-ons for Victoria.  Note the value and  efforts involved  in Refstack & Tempest process was in question and answer is we need to identify pointers in Marketplace to confirm the claims for current Marketpalce efforts.   Here is the summary of Interop WG call today.  1. Interop Guidelines for 2020.10.json  - 2020.10.json  (https://opendev.org/osf/interop) - Arkady to try submit to osf/interop - escale to osf staff if needed ( refer https://review.opendev.org/#/c/762705/1/2020.11.json )- Need pointers to results in Markets 2. Interop add-on Guidelines  for existing - https://opendev.org/osf/interop/src/branch/master/add-ons2.a  DNS (Designate)  - dns.2020.10.json - Need pointers to results 2.b  Orchestration(Heat) -orchestration.2020.10.json - Need pointers results 3. Interop add-on guidelines for new proposals - https://www.openstack.org/marketplace/3.a  FileSystem (Manila) - No plans for Victoria3.b Metal as a Service (Ironic) - No plans for Victoria 4. What's next for Interop 2021 with containers & Kubernetes/magnum ? - Need Volunteers with go skills for new conformance test proposals - Need Board level guidelines from Foundation  Call for volunteers again to ensure we transit from OSF to OIF and please do reply your ideas by email for 1. un-linking orchestration from Heat to Mangnum or Kubernetes as baseline for containers2. Adding new program for BareMetal as a Service with Ironic , bifrost , metal3 etc.3. Putting Integrated OpenStack Integrated logo program on autopilot or terminate  the same at Victoria. ThanksPrakashFor Interop WG OSF/OIF On Friday, November 13, 2020, 11:04:48 AM PST, openstack-discuss-request at lists.openstack.org wrote: Send openstack-discuss mailing list submissions to     openstack-discuss at lists.openstack.org To subscribe or unsubscribe via the World Wide Web, visit     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss or, via email, send a message with subject or body 'help' to     openstack-discuss-request at lists.openstack.org You can reach the person managing the list at     openstack-discuss-owner at lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..." Today's Topics:   1. Re: [release][infra] Discrepancy between release jobs and the       "normal" jobs CI in terms of distro (Jeremy Stanley)   2. [OpenStack][InteropWG] Weekly Interop meeting Agenda for       Victoria Interop Guidelines  in next hr (prakash RAMCHANDRAN)   3. Re: [release][infra] Discrepancy between release jobs and the       "normal" jobs CI in terms of distro (Jeremy Stanley)   4. Re:       [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova       enforces that no DB credentials are allowed for the nova-compute       service (Oliver Walsh) ---------------------------------------------------------------------- Message: 1 Date: Fri, 13 Nov 2020 17:20:44 +0000 From: Jeremy Stanley To: openstack-discuss at lists.openstack.org Subject: Re: [release][infra] Discrepancy between release jobs and the     "normal" jobs CI in terms of distro Message-ID: <20201113172044.c6cgt7rdy6m6mkeu at yuggoth.org> Content-Type: text/plain; charset="utf-8" On 2020-11-13 13:58:18 +0100 (+0100), Radosław Piliszek wrote: [...] > I believe it would be a rare situation but surely testing something on > Bionic and trying to release on Focal might have its quirks. Honestly, I think the real problem here is that we have a bunch of unnecessary cruft in the release-openstack-python job held over from when we used to use tox to create release artifacts. If you look through the log of a successful build you'll see that we're not actually running tox or installing the projects being released, but we're using the ensure-tox and bindep roles anyway. We may not even need ensure-pip in there. The important bits of the job are that it checks out the correct state of the repository and then runs `python3 setup.py sdist bdist_wheel` and then pulls the resulting files back to the executor to be published. That should be fairly consistent no matter what project is being built and no matter what distro it's being built on. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: ------------------------------ Message: 2 Date: Fri, 13 Nov 2020 17:21:06 +0000 (UTC) From: prakash RAMCHANDRAN To: "openstack-discuss at lists.openstack.org"     Subject: [OpenStack][InteropWG] Weekly Interop meeting Agenda for     Victoria Interop Guidelines  in next hr Message-ID: <435519786.5170730.1605288066630 at mail.yahoo.com> Content-Type: text/plain; charset="utf-8" Hi all, Please join me in next hour weekly Interop WG meetingInterop Working Group - Weekly Friday 10-11 AM  PST Link: https://meetpad.opendev.org/Interop-WG-weekly-meetin Agenda: 1. Interop Guidelines for 2020.10.json 2. Interop add-on Guidelines  for existing2.a  DNS (Designate) 2.b  Orchestration(Heat)3. Interop add-on guidelines for new proposals3.a  FileSystem (Manila)3.b Metal as a Service (Ironic)4. What's next for Interop 2021 with containers & Kubernetes/magnum ? - Need Volunteers with go skills for new conformance test proposals ThanksPrakashFor Interop WGOpenDev Etherpad | | |  | OpenDev Etherpad | | | -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Fri, 13 Nov 2020 18:18:05 +0000 From: Jeremy Stanley To: openstack-discuss at lists.openstack.org Subject: Re: [release][infra] Discrepancy between release jobs and the     "normal" jobs CI in terms of distro Message-ID: <20201113181805.wwwlhkqxalbrrbxz at yuggoth.org> Content-Type: text/plain; charset="utf-8" On 2020-11-13 17:20:44 +0000 (+0000), Jeremy Stanley wrote: [...] > Honestly, I think the real problem here is that we have a bunch of > unnecessary cruft in the release-openstack-python job held over > from when we used to use tox to create release artifacts. If you > look through the log of a successful build you'll see that we're > not actually running tox or installing the projects being > released, but we're using the ensure-tox and bindep roles anyway. [...] This solution has been proposed: https://review.opendev.org/762699 -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: ------------------------------ Message: 4 Date: Fri, 13 Nov 2020 19:02:14 +0000 From: Oliver Walsh To: Balázs Gibizer Cc: Javier Pena ,  openstack maillist     , Thomas Goirand     Subject: Re:     [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova     enforces that no DB credentials are allowed for the nova-compute     service Message-ID:     Content-Type: text/plain; charset="utf-8" On Fri 13 Nov 2020, 16:18 Oliver Walsh, wrote: > > > On Fri, 13 Nov 2020 at 10:06, Balázs Gibizer > wrote: > >> >> >> On Thu, Nov 12, 2020 at 06:09, Javier Pena wrote: >> >>  On 11/11/20 5:35 PM, Balázs Gibizer wrote: >> >>  > Dear packagers and deployment engine developers, >> >>  > >> >>  > Since Icehouse nova-compute service does not need any database >> >>  > configuration as it uses the message bus to access data in the >> >> database >> >>  > via the conductor service. Also, the nova configuration guide >> >> states >> >>  > that the nova-compute service should not have the >> >>  > [api_database]connection config set. Having any DB credentials >> >>  > configured for the nova-compute is a security risk as well since >> >> that >> >>  > service runs close to the hypervisor. Since Rocky[1] nova-compute >> >>  > service fails if you configure API DB credentials and set >> >> upgrade_level >> >>  > config to 'auto'. >> >>  > >> >>  > Now we are proposing a patch[2] that makes nova-compute fail at >> >> startup >> >>  > if the [database]connection or the [api_database]connection is >> >>  > configured. We know that this breaks at least the rpm packaging, >> >> debian >> >>  > packaging, and puppet-nova. The problem there is that in an >> >> all-in-on >> >>  > deployment scenario the nova.conf file generated by these tools is >> >>  > shared between all the nova services and therefore nova-compute >> >> sees DB >> >>  > credentials. As a counter-example, devstack generates a separate >> >>  > nova-cpu.conf and passes that to the nova-compute service even in >> >> an >> >>  > all-in-on setup. >> >>  > >> >>  > The nova team would like to merge [2] during Wallaby but we are >> >> OK to >> >>  > delay the patch until Wallaby Milestone 2 so that the packagers >> >> and >> >>  > deployment tools can catch up. Please let us know if you are >> >> impacted >> >>  > and provide a way to track when you are ready with the >> >> modification that >> >>  > allows [2] to be merged. >> >>  > >> >>  > There was a long discussion on #openstack-nova today[3] around >> >> this >> >>  > topic. So you can find more detailed reasoning there[3]. >> >>  > >> >>  > Cheers, >> >>  > gibi >> >> >> >>  IMO, that's ok if, and only if, we all agree on how to implement it. >> >>  Best would be if we (all downstream distro + config management) >> >> agree on >> >>  how to implement this. >> >> >> >>  How about, we all implement a /etc/nova/nova-db.conf, and get all >> >>  services that need db access to use it (ie: starting them with >> >>  --config-file=/etc/nova/nova-db.conf)? >> >> >> > >> > Hi, >> > >> > This is going to be an issue for those services we run as a WSGI app. >> > Looking at [1], I see >> > the app has a hardcoded list of config files to read (api-paste.ini >> > and nova.conf), so we'd >> > need to modify it at the installer level. >> > >> > Personally, I like the nova-db.conf way, since it looks like it >> > reduces the amount of work >> > required for all-in-one installers to adapt, but that requires some >> > code change. Would the >> > Nova team be happy with adding a nova-db.conf file to that list? >> >> Devstack solves the all-in-one case by using these config files: >> >> * nova.conf and api_paste.ini for the wsgi apps e.g. nova-api and >> nova-metadata-api > > * nova.conf for the nova-scheduler and the top level nova-conductor >> (super conductor) >> * nova-cell.conf for the cell level nova-conductor and the >> proxy services, e.g. nova-novncproxy > > * nova-cpu.conf for the nova-compute service >> > > IIUC for nova-metadata-api "it depends": > local_metadata_per_cell=True it needs nova-cell.conf > local_metadata_per_cell=False it needs nova.conf > > Cheers, > Ollie > Also Sean and Dan mentioned the other day that the cell level nova-conductor requires api db access, which I really did not expect. Cheers, Ollie > >> >> The nova team suggest to use a similar strategy to separate files. So > > at the moment we are not planning to change what config files the wsgi >> apps will read. >> >> Cheers, >> gibi >> >> >> > >> > Regards, >> > Javier >> > >> > >> > [1] - >> > >> https://opendev.org/openstack/nova/src/branch/master/nova/api/openstack/wsgi_app.py#L30 >> > >> >>  If I understand well, these services would need access to db: >> >>  - conductor >> >>  - scheduler >> >>  - novncproxy >> >>  - serialproxy >> >>  - spicehtml5proxy >> >>  - api >> >>  - api-metadata >> >> >> >>  Is this list correct? Or is there some services that also don't >> >> need it? >> >> >> >>  Cheers, >> >> >> >>  Thomas Goirand (zigo) >> >> >> >> >> > >> > >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ openstack-discuss mailing list openstack-discuss at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss ------------------------------ End of openstack-discuss Digest, Vol 25, Issue 80 ************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From pramchan at yahoo.com Fri Nov 13 22:01:24 2020 From: pramchan at yahoo.com (prakash RAMCHANDRAN) Date: Fri, 13 Nov 2020 22:01:24 +0000 (UTC) Subject: [OpenStack][OpenInfra][InteropWG] Interop 2021 Brainstorming References: <268579995.5306777.1605304884658.ref@mail.yahoo.com> Message-ID: <268579995.5306777.1605304884658@mail.yahoo.com> Hi all, Request you to consider putting down your ideas for Interop 2021 with Open Infrastructure Foundation (OIF) in your mind. https://etherpad.opendev.org/p/interop2021 If you can add inputs by mid-week next, that will be appreciated. Add your inputs and out-of-box thinking. ThanksPrakashFor Interop WG -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Fri Nov 13 22:06:11 2020 From: smooney at redhat.com (Sean Mooney) Date: Fri, 13 Nov 2020 22:06:11 +0000 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: <864396842.58157343.1605179360197.JavaMail.zimbra@redhat.com> <12CQJQ.RNX7AJ4TRBJ21@est.tech> Message-ID: <6bed70f33d274f34290e4c4a04965d3c97f527b7.camel@redhat.com> On Fri, 2020-11-13 at 19:59 +0000, Oliver Walsh wrote: > On Fri 13 Nov 2020, 16:18 Oliver Walsh, wrote: > > > > > > > On Fri, 13 Nov 2020 at 10:06, Balázs Gibizer > > wrote: > > > > > > > > > > > On Thu, Nov 12, 2020 at 06:09, Javier Pena wrote: > > > > >  On 11/11/20 5:35 PM, Balázs Gibizer wrote: > > > > >  > Dear packagers and deployment engine developers, > > > > >  > > > > > >  > Since Icehouse nova-compute service does not need any database > > > > >  > configuration as it uses the message bus to access data in the > > > > > database > > > > >  > via the conductor service. Also, the nova configuration guide > > > > > states > > > > >  > that the nova-compute service should not have the > > > > >  > [api_database]connection config set. Having any DB credentials > > > > >  > configured for the nova-compute is a security risk as well since > > > > > that > > > > >  > service runs close to the hypervisor. Since Rocky[1] nova-compute > > > > >  > service fails if you configure API DB credentials and set > > > > > upgrade_level > > > > >  > config to 'auto'. > > > > >  > > > > > >  > Now we are proposing a patch[2] that makes nova-compute fail at > > > > > startup > > > > >  > if the [database]connection or the [api_database]connection is > > > > >  > configured. We know that this breaks at least the rpm packaging, > > > > > debian > > > > >  > packaging, and puppet-nova. The problem there is that in an > > > > > all-in-on > > > > >  > deployment scenario the nova.conf file generated by these tools is > > > > >  > shared between all the nova services and therefore nova-compute > > > > > sees DB > > > > >  > credentials. As a counter-example, devstack generates a separate > > > > >  > nova-cpu.conf and passes that to the nova-compute service even in > > > > > an > > > > >  > all-in-on setup. > > > > >  > > > > > >  > The nova team would like to merge [2] during Wallaby but we are > > > > > OK to > > > > >  > delay the patch until Wallaby Milestone 2 so that the packagers > > > > > and > > > > >  > deployment tools can catch up. Please let us know if you are > > > > > impacted > > > > >  > and provide a way to track when you are ready with the > > > > > modification that > > > > >  > allows [2] to be merged. > > > > >  > > > > > >  > There was a long discussion on #openstack-nova today[3] around > > > > > this > > > > >  > topic. So you can find more detailed reasoning there[3]. > > > > >  > > > > > >  > Cheers, > > > > >  > gibi > > > > > > > > > >  IMO, that's ok if, and only if, we all agree on how to implement it. > > > > >  Best would be if we (all downstream distro + config management) > > > > > agree on > > > > >  how to implement this. > > > > > > > > > >  How about, we all implement a /etc/nova/nova-db.conf, and get all > > > > >  services that need db access to use it (ie: starting them with > > > > >  --config-file=/etc/nova/nova-db.conf)? > > > > > > > > > > > > > Hi, > > > > > > > > This is going to be an issue for those services we run as a WSGI app. > > > > Looking at [1], I see > > > > the app has a hardcoded list of config files to read (api-paste.ini > > > > and nova.conf), so we'd > > > > need to modify it at the installer level. > > > > > > > > Personally, I like the nova-db.conf way, since it looks like it > > > > reduces the amount of work > > > > required for all-in-one installers to adapt, but that requires some > > > > code change. Would the > > > > Nova team be happy with adding a nova-db.conf file to that list? > > > > > > Devstack solves the all-in-one case by using these config files: > > > > > > * nova.conf and api_paste.ini for the wsgi apps e.g. nova-api and > > > nova-metadata-api > > > > * nova.conf for the nova-scheduler and the top level nova-conductor > > > (super conductor) > > > * nova-cell.conf for the cell level nova-conductor and the > > > proxy services, e.g. nova-novncproxy > > > > * nova-cpu.conf for the nova-compute service > > > > > > > IIUC for nova-metadata-api "it depends": > > local_metadata_per_cell=True it needs nova-cell.conf > > > > But hang on a second... metadata-api is a wsgi app, which hardcodes > 'nova.conf', so how can this work in devstack? the nova.conf has the db creds in devstack. nova-compute is run with its own config and does not use nova.conf at all we did not really expect nova.conf to be passed as a paramter to the comptue service. > > > local_metadata_per_cell=False it needs nova.conf > > > > Cheers, > > Ollie > > > > > > > > > > The nova team suggest to use a similar strategy to separate files. So > > > > at the moment we are not planning to change what config files the wsgi > > > apps will read. > > > > > > Cheers, > > > gibi > > > > > > > > > > > > > > Regards, > > > > Javier > > > > > > > > > > > > [1] - > > > > > > > https://opendev.org/openstack/nova/src/branch/master/nova/api/openstack/wsgi_app.py#L30 > > > > > > > > >  If I understand well, these services would need access to db: > > > > >  - conductor > > > > >  - scheduler > > > > >  - novncproxy > > > > >  - serialproxy > > > > >  - spicehtml5proxy > > > > >  - api > > > > >  - api-metadata > > > > > > > > > >  Is this list correct? Or is there some services that also don't > > > > > need it? > > > > > > > > > >  Cheers, > > > > > > > > > >  Thomas Goirand (zigo) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owalsh at redhat.com Fri Nov 13 22:33:07 2020 From: owalsh at redhat.com (Oliver Walsh) Date: Fri, 13 Nov 2020 22:33:07 +0000 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: <6bed70f33d274f34290e4c4a04965d3c97f527b7.camel@redhat.com> References: <864396842.58157343.1605179360197.JavaMail.zimbra@redhat.com> <12CQJQ.RNX7AJ4TRBJ21@est.tech> <6bed70f33d274f34290e4c4a04965d3c97f527b7.camel@redhat.com> Message-ID: On Fri 13 Nov 2020, 22:06 Sean Mooney, wrote: > On Fri, 2020-11-13 at 19:59 +0000, Oliver Walsh wrote: > > On Fri 13 Nov 2020, 16:18 Oliver Walsh, wrote: > > > > > > > > > > > On Fri, 13 Nov 2020 at 10:06, Balázs Gibizer > > > wrote: > > > > > > > > > > > > > > > On Thu, Nov 12, 2020 at 06:09, Javier Pena wrote: > > > > > > On 11/11/20 5:35 PM, Balázs Gibizer wrote: > > > > > > > Dear packagers and deployment engine developers, > > > > > > > > > > > > > > Since Icehouse nova-compute service does not need any database > > > > > > > configuration as it uses the message bus to access data in the > > > > > > database > > > > > > > via the conductor service. Also, the nova configuration guide > > > > > > states > > > > > > > that the nova-compute service should not have the > > > > > > > [api_database]connection config set. Having any DB credentials > > > > > > > configured for the nova-compute is a security risk as well > since > > > > > > that > > > > > > > service runs close to the hypervisor. Since Rocky[1] > nova-compute > > > > > > > service fails if you configure API DB credentials and set > > > > > > upgrade_level > > > > > > > config to 'auto'. > > > > > > > > > > > > > > Now we are proposing a patch[2] that makes nova-compute fail > at > > > > > > startup > > > > > > > if the [database]connection or the [api_database]connection is > > > > > > > configured. We know that this breaks at least the rpm > packaging, > > > > > > debian > > > > > > > packaging, and puppet-nova. The problem there is that in an > > > > > > all-in-on > > > > > > > deployment scenario the nova.conf file generated by these > tools is > > > > > > > shared between all the nova services and therefore > nova-compute > > > > > > sees DB > > > > > > > credentials. As a counter-example, devstack generates a > separate > > > > > > > nova-cpu.conf and passes that to the nova-compute service > even in > > > > > > an > > > > > > > all-in-on setup. > > > > > > > > > > > > > > The nova team would like to merge [2] during Wallaby but we > are > > > > > > OK to > > > > > > > delay the patch until Wallaby Milestone 2 so that the > packagers > > > > > > and > > > > > > > deployment tools can catch up. Please let us know if you are > > > > > > impacted > > > > > > > and provide a way to track when you are ready with the > > > > > > modification that > > > > > > > allows [2] to be merged. > > > > > > > > > > > > > > There was a long discussion on #openstack-nova today[3] around > > > > > > this > > > > > > > topic. So you can find more detailed reasoning there[3]. > > > > > > > > > > > > > > Cheers, > > > > > > > gibi > > > > > > > > > > > > IMO, that's ok if, and only if, we all agree on how to > implement it. > > > > > > Best would be if we (all downstream distro + config management) > > > > > > agree on > > > > > > how to implement this. > > > > > > > > > > > > How about, we all implement a /etc/nova/nova-db.conf, and get > all > > > > > > services that need db access to use it (ie: starting them with > > > > > > --config-file=/etc/nova/nova-db.conf)? > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > This is going to be an issue for those services we run as a WSGI > app. > > > > > Looking at [1], I see > > > > > the app has a hardcoded list of config files to read (api-paste.ini > > > > > and nova.conf), so we'd > > > > > need to modify it at the installer level. > > > > > > > > > > Personally, I like the nova-db.conf way, since it looks like it > > > > > reduces the amount of work > > > > > required for all-in-one installers to adapt, but that requires some > > > > > code change. Would the > > > > > Nova team be happy with adding a nova-db.conf file to that list? > > > > > > > > Devstack solves the all-in-one case by using these config files: > > > > > > > > * nova.conf and api_paste.ini for the wsgi apps e.g. nova-api and > > > > nova-metadata-api > > > > > > * nova.conf for the nova-scheduler and the top level nova-conductor > > > > (super conductor) > > > > * nova-cell.conf for the cell level nova-conductor and the > > > > proxy services, e.g. nova-novncproxy > > > > > > * nova-cpu.conf for the nova-compute service > > > > > > > > > > IIUC for nova-metadata-api "it depends": > > > local_metadata_per_cell=True it needs nova-cell.conf > > > > > > > But hang on a second... metadata-api is a wsgi app, which hardcodes > > 'nova.conf', so how can this work in devstack? > the nova.conf has the db creds in devstack. > nova-compute is run with its own config and does not use nova.conf at all > Yes, if its a global metadata api, but for a cell local metadata api it needs to use nova-cell.conf > we did not really expect nova.conf to be passed as a paramter to the > comptue service. > > > > > > local_metadata_per_cell=False it needs nova.conf > > > > > > Cheers, > > > Ollie > > > > > > > > > > > > > > The nova team suggest to use a similar strategy to separate files. So > > > > > > at the moment we are not planning to change what config files the wsgi > > > > apps will read. > > > > > > > > Cheers, > > > > gibi > > > > > > > > > > > > > > > > > > Regards, > > > > > Javier > > > > > > > > > > > > > > > [1] - > > > > > > > > > > https://opendev.org/openstack/nova/src/branch/master/nova/api/openstack/wsgi_app.py#L30 > > > > > > > > > > > If I understand well, these services would need access to db: > > > > > > - conductor > > > > > > - scheduler > > > > > > - novncproxy > > > > > > - serialproxy > > > > > > - spicehtml5proxy > > > > > > - api > > > > > > - api-metadata > > > > > > > > > > > > Is this list correct? Or is there some services that also don't > > > > > > need it? > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Thomas Goirand (zigo) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonyliu0592 at hotmail.com Sat Nov 14 00:34:12 2020 From: tonyliu0592 at hotmail.com (Tony Liu) Date: Sat, 14 Nov 2020 00:34:12 +0000 Subject: [nova-compute] not reconnect to rabbitmq? Message-ID: Hi, I'm having a deployment with Ussuri on CentOS 8. I noticed that, in case the connection from nova-compute to rabbitmq is broken, nova-compute doesn't reconnect. I checked nova-conductor who seems keeping trying reconnect to rabbitmq when connection is broken. But nova-compute doesn't seem doing the same. I've seen it a few times, after I fixed rabbitmq and bring it back, nova-conductor gets reconnected, but nova-compute doesn't, I have to manually restart it. Anyone else has the similar experiences? Anything I am missing? Thanks! Tony From tkajinam at redhat.com Sat Nov 14 04:14:55 2020 From: tkajinam at redhat.com (Takashi Kajinami) Date: Sat, 14 Nov 2020 13:14:55 +0900 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: Message-ID: On Fri, Nov 13, 2020 at 11:19 PM Oliver Walsh wrote: > On Fri 13 Nov 2020, 01:25 Takashi Kajinami, wrote: > >> > For tripleo the first issue to address is in puppet-nova where the dbs >> are currently configured for every nova service. >> > The fix seems trivial - https://review.opendev.org/755689. I also >> think that should be completely safe to backport this to all stable >> branches. >> I don't know whether we can backport that to stable branches. >> I agreed to remove nova::db from the base nova class because we already >> deprecated database parameters in the nova class, but in stable branches >> we have these parameters still valid and removal of nova::db can cause >> some >> issues with these parameters. (I guess pick dosn't work if the nova class >> was >> defined AFTER nova::db class and there are no hieradata used) >> > > I believe you are correct about the pick function. > However I cannot think of any valid use case where the nova class would be > used without also using one of the service specific classes > (nova::api/nova::compute/nova::scheduler). > > i.e if you previously did something like this it would still work: > > class { 'nova': > database_connection => "foobar" > } > include nova::api > > > if you previously did this it didn't work and continues to not work: > > include nova::api > class { 'nova': > database_connection => "foobar" > } > > I thought this could have worked somehow before we removed nova::db from the nova class but as you mentioned this was invalid method even if we have nova::db included, so I was wrong about that. If we don't break any existing usage then I think we are good to backport the fix to stable branches. > if you previously did this you would get db conf, now you will not: > > class { 'nova': > database_connection => "foobar" > } > > I'm not sure what purpose of this would be. I guess if you want to > generate a nova.conf that contains just the config options that are common > to all services... > If that is the use case then the DB creds should not be included, they are > not common to all nova services. > Yeah I don't expect this usage in real deployment, either. > If you are still concerned then in the backports we could continue > including nova::db when any of the deprecated params are set. > > >> So I'd say it's better to leave it in stable branches if nova doesn't >> require >> absence of db parameters in stable branches. >> > >> Note that we can remove these parameters from compute nodes in TripleO >> deployment >> if we completely remove these hieradata from compute nodes. >> > > Compute nodes would be ok but Controllers have nova-compute for ironic. > Single-node all-in-one deployments are obviously an issue too. > > Cheers, > Ollie > > >> Also from puppet's perspective we still need some fixes because the >> standalone >> deployment can still be broken with the change in nova. >> > We need to know what would be the decision made in each distro packaging >> and use the proper config files to store db parameters or the other >> parameters. >> > >> >> >> On Fri, Nov 13, 2020 at 1:43 AM Oliver Walsh wrote: >> >>> IIUC from Sean's reply most of the heavyweight configuration management >>> frameworks already address the security concern. >>> >>> For tripleo the first issue to address is in puppet-nova where the dbs >>> are currently configured for every nova service. The fix seems trivial - >>> https://review.opendev.org/755689. I also think that should be >>> completely safe to backport this to all stable branches. >>> >>> The tripleo changes in https://review.opendev.org/#/c/718552/ are not >>> strictly necessary to remove the db creds from nova.conf. However I need >>> to go further, also removing the hieradata that contains the db creds since >>> completely removing the db creds from the compute hosts is the >>> ultimate goal here. >>> >>> So when the configuration management frameworks are all good then what >>> are we actually concerned about security-wise? Is it just operators that >>> roll their own deployments? >>> >>> Cheers, >>> Ollie >>> >>> On Wed, 11 Nov 2020 at 16:37, Balázs Gibizer >>> wrote: >>> >>>> Dear packagers and deployment engine developers, >>>> >>>> Since Icehouse nova-compute service does not need any database >>>> configuration as it uses the message bus to access data in the database >>>> via the conductor service. Also, the nova configuration guide states >>>> that the nova-compute service should not have the >>>> [api_database]connection config set. Having any DB credentials >>>> configured for the nova-compute is a security risk as well since that >>>> service runs close to the hypervisor. Since Rocky[1] nova-compute >>>> service fails if you configure API DB credentials and set upgrade_level >>>> config to 'auto'. >>>> >>>> Now we are proposing a patch[2] that makes nova-compute fail at startup >>>> if the [database]connection or the [api_database]connection is >>>> configured. We know that this breaks at least the rpm packaging, debian >>>> packaging, and puppet-nova. The problem there is that in an all-in-on >>>> deployment scenario the nova.conf file generated by these tools is >>>> shared between all the nova services and therefore nova-compute sees DB >>>> credentials. As a counter-example, devstack generates a separate >>>> nova-cpu.conf and passes that to the nova-compute service even in an >>>> all-in-on setup. >>>> >>>> The nova team would like to merge [2] during Wallaby but we are OK to >>>> delay the patch until Wallaby Milestone 2 so that the packagers and >>>> deployment tools can catch up. Please let us know if you are impacted >>>> and provide a way to track when you are ready with the modification >>>> that allows [2] to be merged. >>>> >>>> There was a long discussion on #openstack-nova today[3] around this >>>> topic. So you can find more detailed reasoning there[3]. >>>> >>>> Cheers, >>>> gibi >>>> >>>> [1] >>>> >>>> https://github.com/openstack/nova/blob/dc93e3b510f53d5b2198c8edd22528f0c899617e/nova/compute/rpcapi.py#L441-L457 >>>> [2] https://review.opendev.org/#/c/762176 >>>> [3] >>>> >>>> http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2020-11-11.log.html#t2020-11-11T10:51:23 >>>> -- >>>> >>>> http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2020-11-11.log.html#t2020-11-11T14:40:51 >>>> >>>> >>>> >>>> >> >> -- >> ---------- >> Takashi Kajinami >> Senior Software Maintenance Engineer >> Customer Experience and Engagement >> Red Hat >> e-mail: tkajinam at redhat.com >> >> -- ---------- Takashi Kajinami Senior Software Maintenance Engineer Customer Experience and Engagement Red Hat e-mail: tkajinam at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.morin at gmail.com Sat Nov 14 10:10:10 2020 From: arnaud.morin at gmail.com (Arnaud Morin) Date: Sat, 14 Nov 2020 10:10:10 +0000 Subject: [nova-compute] not reconnect to rabbitmq? In-Reply-To: References: Message-ID: <20201114101010.GW8890@sync> Hello, What we noticed in our case is that nova compute is actually reconnecting, but cannot communicate with the conductor because the queue binding is either absent or not working anymore. So, first, which version of nova are you running? Which version of rabbitmq? (some bugs related to shadow bindings are fixed after 3.7.x / dont remember x) Can you check if you have any queue related to your compute? something like that: rabbtitmqctl list_queues | grep mycompute Also check the bindings, better using the management interface or rabbitmqadmin: rabbitmqadmin list bindings | grep mycompute What usually fixed our issue by the past was to delete / recreate the binding (easy to do from the management interface). Cheers, -- Arnaud Morin On 14.11.20 - 00:34, Tony Liu wrote: > Hi, > > I'm having a deployment with Ussuri on CentOS 8. > I noticed that, in case the connection from nova-compute to > rabbitmq is broken, nova-compute doesn't reconnect. > I checked nova-conductor who seems keeping trying reconnect > to rabbitmq when connection is broken. But nova-compute > doesn't seem doing the same. I've seen it a few times, after > I fixed rabbitmq and bring it back, nova-conductor gets > reconnected, but nova-compute doesn't, I have to manually > restart it. Anyone else has the similar experiences? > Anything I am missing? > > > Thanks! > Tony > > From radoslaw.piliszek at gmail.com Sat Nov 14 17:19:54 2020 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Sat, 14 Nov 2020 18:19:54 +0100 Subject: [masakari] Teams cleanup In-Reply-To: References: Message-ID: Dears, Writing to inform you I have made the promised changes to memberships. -yoctozepto On Wed, Nov 4, 2020 at 9:12 PM Radosław Piliszek wrote: > > Hello Everyone! > > To avoid the ghost town effect in Masakari teams, I propose to clean > up the memberships. > I've already had a chance to discuss it with Takashi Kajinami on IRC > [0] as he wanted to remove himself. > > We have 3 teams (1 gerrit, 2 launchpad): > - Gerrit masakari-core [1] > - Launchpad masakari-drivers [2] > - Launchpad masakari-bugs [3] > > I plan to set these to the following people: > - myself [Radosław Piliszek] (the new PTL) > - suzhengwei (new active contributor and core) > - Jegor van Opdorp (new active contributor and core) > - Sampath Priyankara (the previous PTL) > - Tushar Patil (the previously most active core) > > I will enact the change in a week from now if there are no objections. > > I also see a few issues likely to discuss with the infra team: > 1) Launchpad masakari-drivers - there is a pending invitation for the > release team - I doubt it has much use but I would love to see it > accepted/rejected/accepted&removed. > 2) Gerrit masakari-core - there is an external CI in the core team - > why would it need this level of privilege? It does not add its flags > to changes, only replies with job status. > > [0] http://eavesdrop.openstack.org/irclogs/%23openstack-masakari/%23openstack-masakari.2020-10-21.log.html#t2020-10-21T12:42:14 > [1] masakari-core: https://review.opendev.org/#/admin/groups/1448,members > [2] https://launchpad.net/~masakari-drivers/+members > [3] https://launchpad.net/~masakari-bugs/+members > > Kind regards, > > -yoctozepto From zigo at debian.org Sun Nov 15 13:18:13 2020 From: zigo at debian.org (Thomas Goirand) Date: Sun, 15 Nov 2020 14:18:13 +0100 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: Message-ID: <9add2ef9-0f87-dc8a-c8aa-1bd7a0486f02@debian.org> On 11/13/20 2:25 AM, Takashi Kajinami wrote: > We need to know what would be the decision made in each distro packaging > and use the proper config files to store db parameters or the other > parameters. My decision (for Debian) is to move toward using: - nova.conf (as usual, but without any db info) - nova-db.conf - nova-api-db.conf I'll write a function inside openstack-pkg-tools to get this done, and the config files stored in the nova-common package (and the matching debconf scripts poking into the correct new configuration files). I hope Canonical people will follow my lead (could you confirm please?) so we don't have to write special cases for Ubuntu or Debian in puppet-openstack. I will implement this starting with Victoria and on, and patch puppet-openstack. I'll manage to get --config-file as parameters when starting daemons (it's possible to do so, even when using uwsgi). I still don't understand the nova-cell-db.conf thing though. Isn't the connection info for the cells located in the nova-api database? Cheers, Thomas Goirand (zigo) From zigo at debian.org Sun Nov 15 13:20:28 2020 From: zigo at debian.org (Thomas Goirand) Date: Sun, 15 Nov 2020 14:20:28 +0100 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: <4211161605171577@mail.yandex.ru> References: <4211161605171577@mail.yandex.ru> Message-ID: On 11/12/20 10:18 AM, Dmitriy Rabotyagov wrote: > As then it makes sense to do nova-compute.conf as minimal Let's please never use that filename, which is already in use in the Debian package (for selecting the hypervisor type). Cheers, Thomas Goirand (zigo) From oliver.weinmann at me.com Sun Nov 15 15:44:28 2020 From: oliver.weinmann at me.com (Oliver Weinmann) Date: Sun, 15 Nov 2020 16:44:28 +0100 Subject: Which deployment method for ceph (rook|ceph-ansible|tripleo) In-Reply-To: <3BF6161C-B8D5-46E1-ACA3-3516BE901D1F@me.com> References: <20201103151029.dyixpfoput5rgyae@barron.net> <3BF6161C-B8D5-46E1-ACA3-3516BE901D1F@me.com> Message-ID: Hi, just for the sake of completeness. I deployed a 3 node ceph cluster using cephadm and hooked it up to openstack using tripleo. I have to say it was really easy and worked like a charm. The performance is not great but this is something I have to look into next. Thanks again everyone and have a nice day. Am 03.11.2020 um 21:05 schrieb Oliver Weinmann: > Hi Tom, > > Thanks a lot for your input. Highly appreciated. John really convinced me to deploy a > Standalone cluster with cephadm and so I started to deploy It. I stumbled upon a few obstacles, but mostly because commands didn’t behave as expected or myself missing some important steps like adding 3 dashes in a yml file. Cephadm looks really promising. I hope that by tomorrow I will have a simple 3 node cluster. I have to look deeper into it as of how to configure separate networks for the cluster and the Frontend but it shouldn’t be too hard. Once the cluster is functioning I will re-deploy my tripleo POC pointing to the standalone Ceph cluster. Currently I have a zfs nfs Storage configured that I would like to keep. I have to figure out how to configure multiple backends in tripleo. > > Cheers, > Oliver > > Von meinem iPhone gesendet > >> Am 03.11.2020 um 16:20 schrieb Tom Barron : >> >> On 01/11/20 08:55 +0100, Oliver Weinmann wrote: >>> Hi, >>> >>> I'm still in the process of preparing a OpenStack POC. I'm 100% sure that I want to use CEPH and so I purchased the book Mastering CEPH 2nd edition. First of all, It's a really good book. It basically explains the various methods how ceph can be deployed and also the components that CEPH is build of. So I played around a lot with ceph-ansible and rook in my virtualbox environment. I also started to play with tripleo ceph deployment, although I haven't had the time yet to sucessfully deploy a openstack cluster with CEPH. Now I'm wondering, which of these 3 methods should I use? >>> >>> rook >>> >>> ceph-ansible >>> >>> tripleo >>> >>> I also want to use CEPH for NFS and CIFS (Samba) as we have plenty of VMs running under vSphere that currently consume storage from a ZFS storage via CIFS and NFS. I don't know if rook can be used for this. I have the feeling that it is purely meant to be used for kubernetes? And If I would like to have CIFS and NFS maybe tripleo is not capable of enabling these features in CEPH? So I would be left with ceph-ansible? >>> >>> Any suggestions are very welcome. >>> >>> Best Regards, >>> >>> Oliver >>> >>> >> If your core use case is OpenStack (OpenStack POC with CEPH) then of the three tools mentioned only tripleo will deploy OpenStack. It can deploy a Ceph cluster for use by OpenStack as well, or you can deploy Ceph externally and it will "point" to it from OpenStack. For an OpenStack POC (and maybe for production too) I'd just have TripleO deploy the Ceph cluster as well. TripleO will use a Ceph deployment tool -- today, ceph-ansible; in the future, cephadm -- to do the actual Ceph cluster deployment but it figures out how to run the Ceph deployment for you. >> >> I don't think any of these tools will install a Samba/CIFs gateway to CephFS. It's reportedly on the road map for the new cephadm tool. You may be able to manually retrofit it to your Ceph cluster by consulting upstream guidance such as [1]. >> >> NFS shares provisioned in OpenStack (Manila file service) *could* be shared out-of-cloud to VSphere VMs if networking is set up to make them accessible but the shares would remain OpenStack managed. To use the same Ceph cluster for OpenStack and vSphere but have separate storage pools behind them, and independent management, you'd need to deploy the Ceph cluster independently of OpenStack and vSphere. TripleO could "point" to this cluster as mentioned previously. >> >> I agree with your assessment that rook is intended to provide PVs for Kubernetes consumers. You didn't mention Kubernetes as a use case, but as John Fulton has mentioned it is possible to use rook on Kubernetes in a mode where it "points" to an external ceph cluster rather than provisioning its own as well. Or if you run k8s clusters on OpenStack, they can just consume the OpenStack storage, which will be Ceph storage when that is used to back OpenStack Cinder and Manila. >> >> -- Tom Barron >> >> [1] https://www.youtube.com/watch?v=5v8L7FhIyOw&list=PLrBUGiINAakNCnQUosh63LpHbf84vegNu&index=19&t=0s&app=desktop >> From ninorhce at gmail.com Fri Nov 13 21:03:05 2020 From: ninorhce at gmail.com (ninad jadhav) Date: Fri, 13 Nov 2020 13:03:05 -0800 Subject: Failed to Create Virtual Instances for manila Service Due to neutron and nova Services Message-ID: Hi, I am trying to deploy OpenStack, using Openstack installation guide https://docs.openstack.org/install-guide/openstack-services.html#minimal-deployment-for-stein . I am able to launch self-service instance, but during manila(shared-file System) creation I am getting share creation error as per manila-share.log "SSH to default NFS server (10.254.0.0/24) failed. I did all the necessary steps required as per document provided but still not able to create Instances. For Neutron Service I have used Linuxbridge (Networking Option 2). Following are the error logs and configuration file for nova and neutron services. As per my discussion with manila developer manila.conf file looks fine but there is an issue with minimal deploy which allows to create virtual machine but for further manila instance creation its failing due to 1. manila-share.log https://gist.github.com/Ninad-cloud/8c77ccb53df26e6c32505a30c988004c 2. nov-log for instance https://gist.github.com/Ninad-cloud/9129f1c25147e5ee7b874b77e591c9ad 2. controller - neutron all conf files https://gist.github.com/Ninad-cloud/bb25e70007a2bd9ea0848edb081f6525 https://gist.github.com/Ninad-cloud/61b3d357953ddaacc16a926770fbdb72 https://gist.github.com/Ninad-cloud/624a4846157fc294bdfa59093e49fa55 https://gist.github.com/Ninad-cloud/5bb3ad0cb9a38582a7c82816de653693 https://gist.github.com/Ninad-cloud/7366ca93b03f4718a424352fe8ec63e8 https://gist.github.com/Ninad-cloud/56ea190a333cbe0102b676b7de48b7ae 3.compute- neutron all .conf files https://gist.github.com/Ninad-cloud/8b25f38bfcd001177b8f5857f6aacd96 https://gist.github.com/Ninad-cloud/0fba595e3f3cce56695a3fc3c4795d3d https://gist.github.com/Ninad-cloud/c8538c5b00ed2760163c3c73d1247145 https://gist.github.com/Ninad-cloud/73f8bddebf032ea5a5e50023cc7808df 4.controller-nova .conf file https://gist.github.com/Ninad-cloud/4ed5b009a62e9fbc5f9e32ddfb3f1e67 5. compute-nova .conf file https://gist.github.com/Ninad-cloud/f21cd484dd9ad6c0befc66ba3c54457e regards, Ninad -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrxlazuardin at gmail.com Sun Nov 15 18:28:50 2020 From: mrxlazuardin at gmail.com (Lazuardi Nasution) Date: Mon, 16 Nov 2020 01:28:50 +0700 Subject: Clone Cinder-Backed Image (Ussuri) Message-ID: Hi, I have made a cinder-backed image where my cinder is RBD-backed. The backing topology of that image is as follows. glance -> cinder -> RBD. Is it possible to clone that image like RBD-backed images? I think the following bluprint is related but I don't know if it has been implemented yet, at least on Ussuri. https://blueprints.launchpad.net/cinder/+spec/clone-image-in-glance-cinder-backend Best regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrxlazuardin at gmail.com Sun Nov 15 18:43:01 2020 From: mrxlazuardin at gmail.com (Lazuardi Nasution) Date: Mon, 16 Nov 2020 01:43:01 +0700 Subject: Clone Cinder-Backed Image (Ussuri) In-Reply-To: References: Message-ID: Hi, By observation, it seems that if I create a volume from a cinder-backed image where the new volume host is the same with the cinder host of the cinder-backed image, the clone is working. Otherwise, the process is fallback to default. Best regards, On Mon, Nov 16, 2020 at 1:28 AM Lazuardi Nasution wrote: > Hi, > > I have made a cinder-backed image where my cinder is RBD-backed. The > backing topology of that image is as follows. > > glance -> cinder -> RBD. > > Is it possible to clone that image like RBD-backed images? I think the > following bluprint is related but I don't know if it has been > implemented yet, at least on Ussuri. > > > https://blueprints.launchpad.net/cinder/+spec/clone-image-in-glance-cinder-backend > > Best regards, > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonyliu0592 at hotmail.com Sun Nov 15 22:55:03 2020 From: tonyliu0592 at hotmail.com (Tony Liu) Date: Sun, 15 Nov 2020 22:55:03 +0000 Subject: [nova] MessageUndeliverable from nova-conductor and MessagingTimeout from nova-compute Message-ID: It's not about connection, but message transmitting. Title is changed. I am having rabbitmq 3.8.4 and nova 21.0.0. When I check rabbitmq queues for compute, I see 3 messages in compute.compute-1 and 0 messages in other compute node queues. In nova-conductor log of all 3 instances, I see "oslo_messaging.exceptions.MessageUndeliverable". In nova-compute log on compute-1, I see "Timed out waiting for nova-conductor." Actually, 4 out of 5 compute nodes have such warning. One compute node has exception "oslo_messaging.exceptions.MessagingTimeout". "rabbitmqctl list_bindings | grep compute-1" shows this. ================================= exchange compute.compute-1 queue compute.compute-1 [] nova exchange compute.compute-1 queue compute.compute-1 [] ================================= Is this some known issue? How did it happen? What's the cause of it and any way to prevent it from happening? Thanks! Tony > -----Original Message----- > From: Arnaud Morin > Sent: Saturday, November 14, 2020 2:10 AM > To: Tony Liu > Cc: OpenStack Discuss > Subject: Re: [nova-compute] not reconnect to rabbitmq? > > Hello, > > What we noticed in our case is that nova compute is actually > reconnecting, but cannot communicate with the conductor because the > queue binding is either absent or not working anymore. > > So, first, which version of nova are you running? > Which version of rabbitmq? (some bugs related to shadow bindings are > fixed after 3.7.x / dont remember x) > > Can you check if you have any queue related to your compute? > something like that: > rabbtitmqctl list_queues | grep mycompute > > Also check the bindings, better using the management interface or > rabbitmqadmin: > rabbitmqadmin list bindings | grep mycompute > > What usually fixed our issue by the past was to delete / recreate the > binding (easy to do from the management interface). > > Cheers, > > -- > Arnaud Morin > > On 14.11.20 - 00:34, Tony Liu wrote: > > Hi, > > > > I'm having a deployment with Ussuri on CentOS 8. > > I noticed that, in case the connection from nova-compute to rabbitmq > > is broken, nova-compute doesn't reconnect. > > I checked nova-conductor who seems keeping trying reconnect to > > rabbitmq when connection is broken. But nova-compute doesn't seem > > doing the same. I've seen it a few times, after I fixed rabbitmq and > > bring it back, nova-conductor gets reconnected, but nova-compute > > doesn't, I have to manually restart it. Anyone else has the similar > > experiences? > > Anything I am missing? > > > > > > Thanks! > > Tony > > > > From tonyliu0592 at hotmail.com Sun Nov 15 23:24:03 2020 From: tonyliu0592 at hotmail.com (Tony Liu) Date: Sun, 15 Nov 2020 23:24:03 +0000 Subject: [nova] MessageUndeliverable from nova-conductor and MessagingTimeout from nova-compute In-Reply-To: References: Message-ID: This seems the bug tracking this issue. https://bugs.launchpad.net/nova/+bug/1854992 In my case, there is some bunch VM creation initiated by Terraform. I assume it's all about rabbitmq. Any clear way to fix it once it happens, delete and recreate bindings, delete and recreate queues, or just restarting nova-compute? Thanks! Tony > -----Original Message----- > From: Tony Liu > Sent: Sunday, November 15, 2020 2:55 PM > To: Arnaud Morin > Cc: OpenStack Discuss > Subject: [nova] MessageUndeliverable from nova-conductor and > MessagingTimeout from nova-compute > > It's not about connection, but message transmitting. > Title is changed. > I am having rabbitmq 3.8.4 and nova 21.0.0. > > When I check rabbitmq queues for compute, I see 3 messages in > compute.compute-1 and 0 messages in other compute node queues. > In nova-conductor log of all 3 instances, I see > "oslo_messaging.exceptions.MessageUndeliverable". > In nova-compute log on compute-1, I see > "Timed out waiting for nova-conductor." > Actually, 4 out of 5 compute nodes have such warning. > One compute node has exception > "oslo_messaging.exceptions.MessagingTimeout". > > "rabbitmqctl list_bindings | grep compute-1" shows this. > ================================= > exchange compute.compute-1 queue compute.compute- > 1 [] > nova exchange compute.compute-1 queue compute.compute- > 1 [] > ================================= > Is this some known issue? How did it happen? > What's the cause of it and any way to prevent it from happening? > > > Thanks! > Tony > > -----Original Message----- > > From: Arnaud Morin > > Sent: Saturday, November 14, 2020 2:10 AM > > To: Tony Liu > > Cc: OpenStack Discuss > > Subject: Re: [nova-compute] not reconnect to rabbitmq? > > > > Hello, > > > > What we noticed in our case is that nova compute is actually > > reconnecting, but cannot communicate with the conductor because the > > queue binding is either absent or not working anymore. > > > > So, first, which version of nova are you running? > > Which version of rabbitmq? (some bugs related to shadow bindings are > > fixed after 3.7.x / dont remember x) > > > > Can you check if you have any queue related to your compute? > > something like that: > > rabbtitmqctl list_queues | grep mycompute > > > > Also check the bindings, better using the management interface or > > rabbitmqadmin: > > rabbitmqadmin list bindings | grep mycompute > > > > What usually fixed our issue by the past was to delete / recreate the > > binding (easy to do from the management interface). > > > > Cheers, > > > > -- > > Arnaud Morin > > > > On 14.11.20 - 00:34, Tony Liu wrote: > > > Hi, > > > > > > I'm having a deployment with Ussuri on CentOS 8. > > > I noticed that, in case the connection from nova-compute to rabbitmq > > > is broken, nova-compute doesn't reconnect. > > > I checked nova-conductor who seems keeping trying reconnect to > > > rabbitmq when connection is broken. But nova-compute doesn't seem > > > doing the same. I've seen it a few times, after I fixed rabbitmq and > > > bring it back, nova-conductor gets reconnected, but nova-compute > > > doesn't, I have to manually restart it. Anyone else has the similar > > > experiences? > > > Anything I am missing? > > > > > > > > > Thanks! > > > Tony > > > > > > From missile0407 at gmail.com Mon Nov 16 02:43:24 2020 From: missile0407 at gmail.com (Eddie Yen) Date: Mon, 16 Nov 2020 10:43:24 +0800 Subject: [kolla] How to recover MariaDB if there's a controller failed to boot? Message-ID: Hi everyone, We met an issue few days ago. When we launch Openstack cluster, we found that there's a controller couldn't boot up caused by hardware failure, And MariaDB lost sync after left controllers booted into system. In this case, Can I just mark down the failed controller hostname in inventory file and do mariadb_recovery? Any risk after do this after failure one back online? Many thanks, Eddie. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michapma at redhat.com Mon Nov 16 03:08:34 2020 From: michapma at redhat.com (Michael Chapman) Date: Mon, 16 Nov 2020 14:08:34 +1100 Subject: Where to send mascot graphic adjustment proposals Message-ID: While doing some work on the designate docs I wanted to replace the logo on the diagrams (for example https://docs.openstack.org/designate/latest/contributor/architecture.html) with the mascot graphics available, specifically the horizontal one here: https://object-storage-ca-ymq-1.vexxhost.net/swift/v1/6e4619c416ff4bd19e1c087f27a43eea/www-images-prod/project-mascots/Designate/OpenStack_Project_Designate_horizontal.eps The bottom line of the crocodile is just slightly not aligned with the text, which I think could be improved, and perhaps the crocodile could also be increased in size to match that of the text. In addition, the bottom of the mascots page mentions to contact anne at openstack.org which is no longer an active address. Are the above proposed changes reasonable, and is there a new contact available for getting mascot graphics modified? I can change it in the designate diagrams myself but they are marked ND so I don't think that's technically allowed. - Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.morin at gmail.com Mon Nov 16 07:15:09 2020 From: arnaud.morin at gmail.com (Arnaud Morin) Date: Mon, 16 Nov 2020 07:15:09 +0000 Subject: [nova] MessageUndeliverable from nova-conductor and MessagingTimeout from nova-compute In-Reply-To: References: Message-ID: <20201116071509.GX8890@sync> Start by deleting the bindings and recreating them. Then, if not enough, try delete the queues and restart nova-compute. Cheers -- Arnaud Morin On 15.11.20 - 23:24, Tony Liu wrote: > This seems the bug tracking this issue. > https://bugs.launchpad.net/nova/+bug/1854992 > In my case, there is some bunch VM creation initiated by Terraform. > I assume it's all about rabbitmq. Any clear way to fix it once it > happens, delete and recreate bindings, delete and recreate queues, > or just restarting nova-compute? > > Thanks! > Tony > > -----Original Message----- > > From: Tony Liu > > Sent: Sunday, November 15, 2020 2:55 PM > > To: Arnaud Morin > > Cc: OpenStack Discuss > > Subject: [nova] MessageUndeliverable from nova-conductor and > > MessagingTimeout from nova-compute > > > > It's not about connection, but message transmitting. > > Title is changed. > > I am having rabbitmq 3.8.4 and nova 21.0.0. > > > > When I check rabbitmq queues for compute, I see 3 messages in > > compute.compute-1 and 0 messages in other compute node queues. > > In nova-conductor log of all 3 instances, I see > > "oslo_messaging.exceptions.MessageUndeliverable". > > In nova-compute log on compute-1, I see > > "Timed out waiting for nova-conductor." > > Actually, 4 out of 5 compute nodes have such warning. > > One compute node has exception > > "oslo_messaging.exceptions.MessagingTimeout". > > > > "rabbitmqctl list_bindings | grep compute-1" shows this. > > ================================= > > exchange compute.compute-1 queue compute.compute- > > 1 [] > > nova exchange compute.compute-1 queue compute.compute- > > 1 [] > > ================================= > > Is this some known issue? How did it happen? > > What's the cause of it and any way to prevent it from happening? > > > > > > Thanks! > > Tony > > > -----Original Message----- > > > From: Arnaud Morin > > > Sent: Saturday, November 14, 2020 2:10 AM > > > To: Tony Liu > > > Cc: OpenStack Discuss > > > Subject: Re: [nova-compute] not reconnect to rabbitmq? > > > > > > Hello, > > > > > > What we noticed in our case is that nova compute is actually > > > reconnecting, but cannot communicate with the conductor because the > > > queue binding is either absent or not working anymore. > > > > > > So, first, which version of nova are you running? > > > Which version of rabbitmq? (some bugs related to shadow bindings are > > > fixed after 3.7.x / dont remember x) > > > > > > Can you check if you have any queue related to your compute? > > > something like that: > > > rabbtitmqctl list_queues | grep mycompute > > > > > > Also check the bindings, better using the management interface or > > > rabbitmqadmin: > > > rabbitmqadmin list bindings | grep mycompute > > > > > > What usually fixed our issue by the past was to delete / recreate the > > > binding (easy to do from the management interface). > > > > > > Cheers, > > > > > > -- > > > Arnaud Morin > > > > > > On 14.11.20 - 00:34, Tony Liu wrote: > > > > Hi, > > > > > > > > I'm having a deployment with Ussuri on CentOS 8. > > > > I noticed that, in case the connection from nova-compute to rabbitmq > > > > is broken, nova-compute doesn't reconnect. > > > > I checked nova-conductor who seems keeping trying reconnect to > > > > rabbitmq when connection is broken. But nova-compute doesn't seem > > > > doing the same. I've seen it a few times, after I fixed rabbitmq and > > > > bring it back, nova-conductor gets reconnected, but nova-compute > > > > doesn't, I have to manually restart it. Anyone else has the similar > > > > experiences? > > > > Anything I am missing? > > > > > > > > > > > > Thanks! > > > > Tony > > > > > > > > > From jocelyn.thode at elca.ch Mon Nov 16 07:52:38 2020 From: jocelyn.thode at elca.ch (Thode Jocelyn) Date: Mon, 16 Nov 2020 07:52:38 +0000 Subject: CloudKitty deployment on Train and/or Ussuri In-Reply-To: <442787327.5847224.1605268274504.JavaMail.zimbra@tubitak.gov.tr> References: <29a0ff29af9d4314bdc2e0b2bc69cc8f@elca.ch> <442787327.5847224.1605268274504.JavaMail.zimbra@tubitak.gov.tr> Message-ID: <62ccf553f03e445c9e4dc267c0ad36b1@elca.ch> Hi Pierre, On our side we are using Train running in LXC containers with Ubuntu 18.04. From what I see from the role it installed Cloudkitty using pip. Regards Jocelyn Thode From: Gökhan IŞIK - TÜBİTAK BİLGEM Sent: vendredi, 13 novembre 2020 12:51 To: Pierre Riteau Cc: Thode Jocelyn ; Henry Bonath ; openstack-discuss at lists.openstack.org Subject: Re: CloudKitty deployment on Train and/or Ussuri Hi Thode and Pierre, I am also an OSA user. We are using cloudkitty in our pike environment. we are now upgrading our environment to ussuri version. We are planning to use cloudkitty again. At pike version, ı have some updates on cloudkitty role[1]. ı will work on cloudkitty ussuri version next week. We can make cloudkitty run. We can contact on #openstack-ansible irc channel. ı hope we can make cloudkitty run successfully. [1] https://github.com/b3lab/openstack-ansible-os_cloudkitty/tree/stable/pike/ Best wishes, Gökhan IŞIK (gokhani) ________________________________ Kimden: "Pierre Riteau" > Kime: "Thode Jocelyn" > Kk: "Henry Bonath" >, openstack-discuss at lists.openstack.org Gönderilenler: 13 Kasım Cuma 2020 14:28:26 Konu: Re: CloudKitty deployment on Train and/or Ussuri ThodeHi Thode and Henry, The CloudKitty role in OSA is using configuration options that were deprecated back in 9.0.0 (Stein) and deleted in 11.0.0 (Train). As I am not an OSA user (I use Kolla Ansible which supports CloudKitty well), I encourage you to submit your fixes to OSA. About the error you are seeing in cloudkitty-api, I haven't seen this before. Could you give more information about your deployment? Are you using a packaged version (deb / rpm) or source? What is your Linux distribution? Best wishes, Pierre Riteau (priteau) On Fri, 13 Nov 2020 at 11:50, Thode Jocelyn > wrote: Hi Henry, Unfortunately as I did not get any answer I had stop investigating cloud kitty for the moment, so I was not able to make cloudkitty-api work. For now we have put this task in standby and looking at other alternatives from afar. Let me know if you make any progress on your end. I'll let you know if we start working again on Cloudkitty on our side Cheers Jocelyn -----Original Message----- From: Henry Bonath > Sent: mardi, 10 novembre 2020 21:24 To: Thode Jocelyn > Cc: openstack-discuss at lists.openstack.org Subject: Re: CloudKitty deployment on Train and/or Ussuri Hi Jocelyn, I am also an Openstack-Ansible user, who is in the same market of trying to find Rating-as-A-Service for my Train cloud. I stumbled upon your message here after running into the same exact issue that you are having and searching for answers, and am glad to hear that I am not alone. (Don't you hate when you only find more questions??) I am testing Cloudkitty v13.0.0 right now and running into the same issue as you are as it relates to 'cloudkitty-api'. I also found that the templated config you referenced needs to be updated as well. I'm going to continue to soldier through this and try to get a working configuration, were you able to make any progress on the issue with cloudkitty-api? Please let me know if we can work together to get this working, I can submit any patches to the openstack-ansible-os_cloudkitty repo. -Henry On Fri, Oct 23, 2020 at 2:38 AM Thode Jocelyn > wrote: > > Hi, > > > > I was looking at the possibilities to have Rating-as-A-Service in our > Openstack (currently train but planning to move to Ussuri) and I > stumbled upon CloudKitty. I’m currently facing multiple issues with > cloudkitty itself and with openstack-ansible. (We are using a > containerized deployment with LXC) > > > > I noticed that openstack-ansible has no playbook yet to install a service like CloudKitty even though starting from Ussuri it was added in the ansible-role-requirements.yml. I have created a small patch to be able to install CloudKitty via openstack-ansible and if this is of interest I could potentially submit a PR with this. > The os_cloudkitty role seems to kinda work and only with a relatively old version of CloudKitty. For example, here : https://opendev.org/openstack/openstack-ansible-os_cloudkitty/src/branch/stable/train/templates/cloudkitty.conf.j2#L38 since CloudKitty v8.0.0 the section should be named “[fetcher_keystone]”, but I found no information as to which CloudKitty version should be used with this role. Does someone have any recommendation as to which version should be used and if there is any interest in improving the role to support more recent versions of CloudKitty? > Even when tweaking the configuration and installing v7.0.0 of Cloudkitty it only fixes cloudkitty-processor, I was never able to make cloudkitty-api work I always get an error like “Fatal Python error: Py_Initialize: Unable to get the locale encoding ModuleNotFoundError: No module named 'encodings'”. Any input on this would be greatly appreciated. > > > > > Cheers > > Jocelyn -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Mon Nov 16 08:04:03 2020 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Mon, 16 Nov 2020 09:04:03 +0100 Subject: [kolla] How to recover MariaDB if there's a controller failed to boot? In-Reply-To: References: Message-ID: On Mon, Nov 16, 2020 at 3:52 AM Eddie Yen wrote: > > Hi everyone, > Hi Eddie! > We met an issue few days ago. When we launch Openstack cluster, we found > that there's a controller couldn't boot up caused by hardware failure, And MariaDB > lost sync after left controllers booted into system. > In this case, Can I just mark down the failed controller hostname in inventory file and > do mariadb_recovery? Any risk after do this after failure one back online? It is supposed to be used like you are saying. As long as the alive controllers have all the data you need, it will work fine. They should if they were up before failure. The failed one will either be unable to rejoin the cluster or just follow the others. It depends on its local state. It will not impose its state on others so it is safe to turn it on and then fix it. (All the above assumes standard configuration) > > Many thanks, > Eddie. -yoctozepto From mark at stackhpc.com Mon Nov 16 09:28:22 2020 From: mark at stackhpc.com (Mark Goddard) Date: Mon, 16 Nov 2020 09:28:22 +0000 Subject: [kolla] Proposing wu.chunyang for Kolla core In-Reply-To: References: Message-ID: On Mon, 9 Nov 2020 at 11:33, Mark Goddard wrote: > > Hi, > > I would like to propose adding wu.chunyang to the kolla-core and > kolla-ansible-core groups. wu.chunyang did some great work on Octavia > integration in the Victoria release, and has provided some helpful > reviews. > > Cores - please reply +1/-1 before the end of Friday 13th November. Thanks everyone, and welcome to the team, wu.chunyang! I have updated the kolla-core and kolla-ansible-core groups in Gerrit, as well as the kolla-drivers Launchpad group. > > Thanks, > Mark From lucasagomes at gmail.com Mon Nov 16 09:49:54 2020 From: lucasagomes at gmail.com (Lucas Alvares Gomes) Date: Mon, 16 Nov 2020 09:49:54 +0000 Subject: [neutron] Bug Deputy Report Nov 9-16 Message-ID: Hi, This is the Neutron bug report of the week of 2020-11-09. Critical: * https://bugs.launchpad.net/neutron/+bug/1903982 - "[neutron-tempest-plugin] Error when executing "hostname" in the VM" Assigned to: Rodolfo Alonso * https://bugs.launchpad.net/neutron/+bug/1903531 - "Update of neutron-server breaks compatibility to previous neutron-agent version" Unassigned High: * https://bugs.launchpad.net/neutron/+bug/1904117 - "Nodes in the OVN scenario multinode jobs can't talk to each other" Assigned to: slaweq * https://bugs.launchpad.net/neutron/+bug/1903985 - " [functional] Timeouts during setting link attributes in the namepaces" Unassigned * https://bugs.launchpad.net/neutron/+bug/1903696 - "Security group OVO object don't reloads and make compatible rules objects" Assigned to: slaweq * https://bugs.launchpad.net/neutron/+bug/1903696 - "Security group OVO object don't reloads and make compatible rules objects" Assigned to: slaweq * https://bugs.launchpad.net/neutron/+bug/1903985 - "[functional] Timeouts during setting link attributes in the namepaces" Unassigned Medium: * https://bugs.launchpad.net/neutron/+bug/1903989 - " Bug in logging potentionally causing neutron to fail" Assigned to: Michal Arbet * https://bugs.launchpad.net/neutron/+bug/1903689 - "[stable/ussuri] Functional job fails - AttributeError: module 'neutron_lib.constants' has no attribute 'DEVICE_OWNER_DISTRIBUTED'" Unassigned * https://bugs.launchpad.net/neutron/+bug/1903433 - "The duplicate route in l3 router namespace results in North-South traffic breaking" Assigned to: yangjianfeng * https://bugs.launchpad.net/neutron/+bug/1903689 - "stable/ussuri] Functional job fails - AttributeError: module 'neutron_lib.constants' has no attribute 'DEVICE_OWNER_DISTRIBUTED" Unassigned * https://bugs.launchpad.net/neutron/+bug/1903982 - " [neutron-tempest-plugin] Error when executing "hostname" in the VM" Assigned to: Rodolfo Alonso * https://bugs.launchpad.net/neutron/+bug/1903989 - " Bug in logging potentionally causing neutron to fail" Assigned to: michalarbet Needs further triage: * https://bugs.launchpad.net/neutron/+bug/1904178 - "[ovn] neutron not support Vlan backed DVR N-Sredirect packet via localnet port," Unassigned * https://bugs.launchpad.net/neutron/+bug/1904041 - " Victoria neutron-db-sync fails with I38991de2b4_source_and_destination_ip_prefix_neutron_metering_rule.py" Unassigned * https://bugs.launchpad.net/neutron/+bug/1903835 - " linuxbridge-agent ERRORS with pyroute2.netlink.exceptions.NetlinkError if ipv6 link local address exist " Unassigned * https://bugs.launchpad.net/neutron/+bug/1903835 - "linuxbridge-agent ERRORS with pyroute2.netlink.exceptions.NetlinkError if ipv6 link local address exist" Unassigned Wishlist: * https://bugs.launchpad.net/neutron/+bug/1904188 - "Include standard attributes ID in OVO dictionaries to improve the OVN revision numbers operation" Assigned to: Rodolfo Alonso From thierry at openstack.org Mon Nov 16 09:56:55 2020 From: thierry at openstack.org (Thierry Carrez) Date: Mon, 16 Nov 2020 10:56:55 +0100 Subject: [largescale-sig] Next meeting: November 18, 14utc Message-ID: Hi everyone, After a well-deserved break after the Summit and the PTG, the Large Scale SIG is back with regular meetings this Wednesday in #openstack-meeting-3 on IRC, at our new time: 14UTC. See how it translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201118T14 Feel free to add topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting Talk to you all later, -- Thierry Carrez From katonalala at gmail.com Mon Nov 16 10:17:24 2020 From: katonalala at gmail.com (Lajos Katona) Date: Mon, 16 Nov 2020 11:17:24 +0100 Subject: [all][healthcheck] Message-ID: Hi, I send this mail out to summarize the discussion around Healthcheck API on Neutron PTG, and start a discussion how we can make this most valuable to the operators. On the Neutron PTG etherpad this topic is from L114: https://etherpad.opendev.org/p/neutron-wallaby-ptg . Background: oslo_middleware provides /healthcheck API path(see [1]), which can be used to poll by services like haproxy, and gives a plugin mechanism to add some more complicated checks, which can be switched on/off from config. The main questions: - Some common guidance what to present to the operators (if you check [2] and [3] in the comments there are really good questions/concerns) - Perhaps the API SIG has something about healtcheck, just I can't find it. - What to present with and without authentication (after checking again, I am not sure that it is possible to use authentication for the healthcheck) - A way forward can be to make it configurable with default to authenticated, and give the decision to the admin. - During the discussion the agreement was to separate the frontend health from the backend health and use direct indicators (like working db connectivity, and mq connectivity) instead of indirect indicators (like agents' health). Thanks in advance for the feedback. [1] https://docs.openstack.org/oslo.middleware/latest/reference/healthcheck_plugins.html [2] https://review.opendev.org/731396 [3] https://review.opendev.org/731554 Regards Lajos Katona (lajoskatona) -------------- next part -------------- An HTML attachment was scrubbed... URL: From giacomo.lanciano at sns.it Mon Nov 16 10:23:27 2020 From: giacomo.lanciano at sns.it (Giacomo Lanciano) Date: Mon, 16 Nov 2020 11:23:27 +0100 Subject: [monasca] Predictive Analytics Message-ID: Hi all, I am new to this community, as I have only recently started using OpenStack in my research. I am working on designing an "intelligent" auto-scaling mechanism, based on resources consumption metrics forecasts, leveraging on Monasca for metrics ingestion and processing. Digging into the Wiki/Documentation, I have stumbled upon the recently retired "monasca-analytics", that seems to cover pretty much (and way more of) what I had in mind to build on top of the monitoring component, to enable proactive auto-scaling decisions. I am very interested in knowing more about why such project has been abandoned and, more importantly, whether the effort has been redirected to another project that I am not aware of. Could you point me to any resource that you consider useful to contribute on these topics? Thanks in advance. Kind Regards. Giacomo -- Giacomo Lanciano Ph.D. Student in Data Science Scuola Normale Superiore, Pisa, Italy https://www.linkedin.com/in/giacomolanciano From missile0407 at gmail.com Mon Nov 16 10:33:22 2020 From: missile0407 at gmail.com (Eddie Yen) Date: Mon, 16 Nov 2020 18:33:22 +0800 Subject: [kolla] How to recover MariaDB if there's a controller failed to boot? In-Reply-To: References: Message-ID: Hi yoctozepto, thanks your advice. Perhaps need to do maraidb_recovery again once the failure node back online to prevent brain split issue. But we'll try it if we met the same case again in the future! Thank you very much, Eddie. Radosław Piliszek 於 2020年11月16日 週一 下午4:04寫道： > On Mon, Nov 16, 2020 at 3:52 AM Eddie Yen wrote: > > > > Hi everyone, > > > > Hi Eddie! > > > We met an issue few days ago. When we launch Openstack cluster, we found > > that there's a controller couldn't boot up caused by hardware failure, > And MariaDB > > lost sync after left controllers booted into system. > > In this case, Can I just mark down the failed controller hostname in > inventory file and > > do mariadb_recovery? Any risk after do this after failure one back > online? > > It is supposed to be used like you are saying. > As long as the alive controllers have all the data you need, it will work > fine. > They should if they were up before failure. > The failed one will either be unable to rejoin the cluster or just > follow the others. > It depends on its local state. > It will not impose its state on others so it is safe to turn it on and > then fix it. > > (All the above assumes standard configuration) > > > > > Many thanks, > > Eddie. > > -yoctozepto > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephenfin at redhat.com Mon Nov 16 10:41:43 2020 From: stephenfin at redhat.com (Stephen Finucane) Date: Mon, 16 Nov 2020 10:41:43 +0000 Subject: [nova] How best to provide virtio-based input devices? In-Reply-To: References: Message-ID: On Thu, 2020-11-12 at 11:50 -0800, Dan Smith wrote: > Design discussion for interested parties. As discussed during the > nova > team meeting today, we're looking at providing support for virtio- > based > input devices in nova, given benefits w.r.t. performance and security > (no emulated USB bus!). The current proposal I have for this is to > introduce a new image metadata property, 'hw_input_bus', and extend > the > existing 'hw_pointer_model' image metadata property, which currently > only accepts a 'usbtablet' value, to accept 'mouse' or 'tablet' > values. > This means you'd end up with a matrix something like so: > >   +------------------+--------------+------------------------+ >   | hw_pointer_model | hw_input_bus | Result                 | >   +------------------|--------------+------------------------+ >   | -                | -            | PS2-based mouse [*]    | >   | usbtablet        | -            | USB-based tablet       | >   | usbtablet        | usb          | USB-based tablet       | >   | usbtablet        | virtio       | **ERROR**              | >   | mouse            | -            | USB-based mouse        | >   | mouse            | usb          | USB-based mouse        | >   | mouse            | virtio       | virtio-based mouse     | >   | tablet           | -            | USB-based tablet       | >   | tablet           | usb          | USB-based tablet       | >   | tablet           | virtio       | virtio-based tablet    | >   +------------------+--------------+------------------------+ Yeah, my complaint here is that there are too many ways to describe things that can't possibly work, in addition to the things you might ask for that aren't supported by your virt driver (which are unavoidable). > dansmith noted that the only reason to select the 'mouse' pointer > model > nowadays is for compatibility, and something like a virtio-based > mouse > didn't really make sense. That being the case, I agree that this > change > is likely more complex that it needs to be. We do, however, disagree > on > the remedy. dansmith's idea is to drop the 'hw_input_bus' image > metadata property entirely and simply add a new 'virtiotablet' value > to > 'hw_pointer_model' instead. Just for clarification, I want to drop the _new_ parameter from the _proposal_, as in not add it in the first place. > This still leaves the question of what bus we should use for > keyboards, and his suggestion there is to extrapolate out and use > virtio for keyboards if 'hw_pointer_model=virtiotablet' is specified > and presumably USB if 'hw_pointer_model=usbtablet'. Indeed. That leaves you with no new image metadata keys, no new object structural changes, deprecation implications thereof, and just a single new value for the existing key of "virtiotablet" (or even just "virtio"). I don't really care whether or not we change the usb case from how it works today. I think most people that care a lot about how the graphical console works are probably looking for pointer support more than anything else. > > Needless to say, I don't like this idea and prefer we took another > tack > and kept 'hw_input_bus'  but didn't build on 'hw_pointer_model' and > instead "deprecated" it. We can't really ever remove the an image > metadata property, since that would be a breaking upgrade, which > means > we'll eventually be left with effectively dead code to maintain > forever. However, I don't think that's a big deal. Right, so this is what I don't like. Users will come along trying to figure out how to get either a USB tablet or a virtio pointer, and be presented with a bunch of options. For years, google will return them results that point to the existing key that omit the new option. If they google for updated docs for that key, they won't find a new virtio-based value that they can use, but will hopefully find the explanation and truth table of how to get what they want, depending on how new or old their cloud is, what virt driver it's running, how new that virt driver is, and what platform they're using. And of course, we have to decide what to do if they specify both keys if they're confused by the forumla for deciding which to use. I'd much prefer to retain compatibility with images from the last ten years (or however long we've allowed this to be specified) and just add another value for the new model. Obviously "hw_pointer_model" isn't the nicest name, given that we're using it to determine both input devices, but I don't think that wrecking google results, docs, and people's images is really worth it. It's important to consider that people do have images and code that work on multiple clouds running various versions. It seems a lot nicer to me to just keep using the key that works everywhere, extended for the new value where available. This is all very misleading. Deprecation does not equal deprecation for removal. We can and will continue to support the old 'hw_pointer_model' option until such a time as we provide a way to automatically migrate images (and flavours) from an older format to a newer one, or forever if we never do this. Old Google results, docs, and people's images will all remain valid. Nothing is wrecked and nothing actually changes until you decide to use the new, easily understood image metadata property. There's also a suggestion here that 'hw_pointer_model' is a widely used, well understood image metadata property. The three pages of results I see on Google, most of which are from clones of the nova git repo, suggest otherwise. I'd wager that few if any users are actually using this, given this is also configurable at a host level via the '[DEFAULT] pointer_model' option, which defaults to a USB-based tablet. There isn't a lot to save here. Conversely, there something to lose by building upon rotten foundations. Ultimately, 'hw_input_bus' is self-explanatory and aligns very well with existing properties like 'hw_disk_bus'. 'hw_pointer_model' with the "spooky behaviour at a distance" behaviour that's been proposed is neither. I think the 5 lines of code necessary to add a 'hw_input_bus' field to the 'ImageMetadataProps' object and handle potential conflicts with the legacy 'hw_pointer_model' are not worth worrying about, and would be a net positive once the UX improvements are taken into account. Can we just do this? Stephen --Dan From stephenfin at redhat.com Mon Nov 16 10:41:53 2020 From: stephenfin at redhat.com (Stephen Finucane) Date: Mon, 16 Nov 2020 10:41:53 +0000 Subject: [nova] How best to provide virtio-based input devices? In-Reply-To: References: Message-ID: <1a1b556fb4c832d15067991741deaedb71c6fbad.camel@redhat.com> On Thu, 2020-11-12 at 17:09 -0800, melanie witt wrote: On 11/12/20 11:03, Stephen Finucane wrote: > Design discussion for interested parties. As discussed during the > nova > team meeting today, we're looking at providing support for virtio- > based > input devices in nova, given benefits w.r.t. performance and security > (no emulated USB bus!). The current proposal I have for this is to > introduce a new image metadata property, 'hw_input_bus', and extend > the > existing 'hw_pointer_model' image metadata property, which currently > only accepts a 'usbtablet' value, to accept 'mouse' or 'tablet' > values. > This means you'd end up with a matrix something like so: > >    +------------------+--------------+------------------------+ >    | hw_pointer_model | hw_input_bus | Result                 | >    +------------------|--------------+------------------------+ >    | -                | -            | PS2-based mouse [*]    | >    | usbtablet        | -            | USB-based tablet       | >    | usbtablet        | usb          | USB-based tablet       | >    | usbtablet        | virtio       | **ERROR**              | >    | mouse            | -            | USB-based mouse        | >    | mouse            | usb          | USB-based mouse        | >    | mouse            | virtio       | virtio-based mouse     | >    | tablet           | -            | USB-based tablet       | >    | tablet           | usb          | USB-based tablet       | >    | tablet           | virtio       | virtio-based tablet    | >    +------------------+--------------+------------------------+ > >    [*] libvirt adds these by default on x86 hosts > > dansmith noted that the only reason to select the 'mouse' pointer > model > nowadays is for compatibility, and something like a virtio-based > mouse > didn't really make sense. That being the case, I agree that this > change > is likely more complex that it needs to be. +1, agree that having several user choices for pointer + bus that result in invalid or nonsensical combinations would not be a positive UX. > We do, however, disagree on > the remedy. dansmith's idea is to drop the 'hw_input_bus' image > metadata property entirely and simply add a new 'virtiotablet' value > to > 'hw_pointer_model' instead. This still leaves the question of what > bus > we should use for keyboards, and his suggestion there is to > extrapolate > out and use virtio for keyboards if 'hw_pointer_model=virtiotablet' > is > specified and presumably USB if 'hw_pointer_model=usbtablet'. > > Needless to say, I don't like this idea and prefer we took another > tack > and kept 'hw_input_bus'  but didn't build on 'hw_pointer_model' and > instead "deprecated" it. We can't really ever remove the an image > metadata property, since that would be a breaking upgrade, which > means > we'll eventually be left with effectively dead code to maintain > forever. However, I don't think that's a big deal. > 'hw_pointer_model=usbtablet' is already on a path to obsolescence as > the Q35 machine type slowly becomes the default on x86 hosts and the > use of non-x86 hosts grows since neither support PS2 and must use a > USB-based input device. In addition, I think the extrapolation of > 'virtiotablet' to mean also virtio-based keyboard is unclear and > leaves > a gaping hole w.r.t. requesting USB-based keyboards on non-AArch64 > hosts (where it's currently added by default), since we don't > currently > do this extrapolation and introducing it would be breaking change on > x86 hosts (instances would suddenly switch from PS2-based keyboards > to > USB-based ones). If I understand correctly, we do choose the "best fit" keyboard based on architecture, independent of the requested hw_pointer_model, today. Not quite. libvirt on x86 will automatically add a PS2 mouse and keyboard (even if you request something else) because that's what QEMU does. On all other platforms (to the best of my knowledge, based on Kashyap quizzing a handful of multi-arch libvirt devs), this must be done manually. We currently only do this for AArch64, through the non- configurable addition of a USB keyboard [1]. There is currently no way to request e.g. a USB or virtio keyboard on any architecture. [1] https://github.com/openstack/nova/commit/b92e3bc95fd It feels like it would be simpler to continue doing that and add a virtio choice to hw_pointer_model and let the driver pick the "best" keyboard to go along with that. Is it your view that having the  > driver choose a virtio keyboard if hw_pointer_model=virtiotablet is > inconsistent with the existing "best fit" keyboard selection > behavior? My concerns are twofold. Firstly, having the value of 'hw_pointer_model' influence the keyboard bus is poor UX, since this "feature" is not at all apparent from the property name. Secondly, 'hw_pointer_model' is a poorly designed property, given it configured the bus as well as the model, munging the two. To be clear, I agree that having different buses for keyboard and pointer makes no sense. There's no reason they shouldn't be the same. I'm just saying that configuring the bus for input devices via an appropriately named 'hw_input_bus' image metadata property makes much more sense that maybe getting one configured magically based on the "pointer model" in use. >From what I understand, the pointer is the only user selection we can guarantee and the keyboard is architecture dependent. Again, not really. There isn't an analog for pointer vs. mouse when it comes to keyboards. The keyboard isn't architecture dependent. What is architecture dependent is whether you get a keyboard and mouse by default (yes on x86, in the form of a PS2 mouse and keyboard, and no for everyone else). > If we "deprecated" hw_pointer_model and introduced hw_input_bus, how does > the user know which thing (pointer or keyboard) they are specifying?  > If users can't actually choose the keyboard and can only choose the pointer, wouldn't presenting a selection of a generic "hw_input_bus" be more confusing > than hw_pointer_model? They can choose the _bus_ that the keyboard uses. There's an assumption here that if you request a graphics device (VNC, SPICE, ...) then you will get a keyboard and tablet input devices, because that graphics device is unusable otherwise. There is also an assumption (based on dansmith's comments about mouse being only used for legacy compat reasons) that the user will never want to explicitly request a 'mouse' pointer model and should therefore get 'tablet' by default. Based on these two assumptions, the only thing remaining is to decide how the keyboard and tablet devices will be attached to the guest...achieved via a sensibly named 'hw_input_bus' image metadata property. That seems reasonable to me. Stephen Best, -melanie > We need to decide what approach to go for before I rework this. If > anyone has input, particularly operators that think they'd use this > feature, I'd love to hear it so that I can t̶e̶l̶l̶ ̶d̶a̶n̶s̶m̶i̶t̶h̶ > ̶t̶o̶ ̶s̶h̶o̶v̶e̶ ̶i̶t̶ come to the best possible solution ;-) Feel > free to either reply here or on the review [1]. > > Cheers, > Stephen > > [1] https://review.opendev.org/#/c/756552/ > > From hberaud at redhat.com Mon Nov 16 13:50:40 2020 From: hberaud at redhat.com (Herve Beraud) Date: Mon, 16 Nov 2020 14:50:40 +0100 Subject: [oslo] following or not following the DST changes for our meeting time Message-ID: Hello Oslofolk, As discussed during our previous meeting, at each DST change, the agenda of some of us conflicting with our Oslo meeting time slot, this thread just wants to propose a solution to avoid that. We could just move our meeting time when DST changes, and then move back to this slot once DST is back. Right now our meeting time is UTC based, we suppose that UTC is required because of the OpenStack meeting tooling. By following that we will get the following time slots: - meeting time slot when DST start: 5:00pm UTC - meeting time slot when DST end: 4:00pm UTC Does it fit well for you? -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko.vancsa at gmail.com Mon Nov 16 14:10:40 2020 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Mon, 16 Nov 2020 15:10:40 +0100 Subject: [edge] Open Geospatial Consortium presentation on the next Edge WG call In-Reply-To: <25BF983B-A24A-4F66-8F52-E106DFA9FBA4@gmail.com> References: <25BF983B-A24A-4F66-8F52-E106DFA9FBA4@gmail.com> Message-ID: Hi, It is a friendly reminder that if you are interested in the presentation the call is already on! :) Zoom link: https://zoom.us/j/99125523469?pwd=QW1ITndrdlhHaWZHVkFWNjBJemxRdz09 Thanks, Ildikó > On Nov 10, 2020, at 17:46, Ildiko Vancsa wrote: > > Hi, > > I’m reaching out to draw your attention to an upcoming presentation on the Edge Computing Group weekly call next Monday. > > We will have a presentation from the Open Geospatial Consortium where you can learn about their use cases relevant to edge computing and more specifically about the importance of location in that context. In the remaining time on the call we will discuss some of the requirements of the use cases such as location-awareness of infrastructure services and look into collaboration opportunities. > > The call is on __Monday (November 16) at 1400 UTC__. > > If you are interested in joining the call and the discussions you can find the dial-in information here: https://wiki.openstack.org/wiki/Edge_Computing_Group#Next_meeting:_Monday_.28November_16.29.2C_6am_PST_.2F_1400_UTC > > Please let me know if you have any questions. > > Thanks, > Ildikó > > From amy at demarco.com Mon Nov 16 14:30:16 2020 From: amy at demarco.com (Amy Marrich) Date: Mon, 16 Nov 2020 08:30:16 -0600 Subject: Victoria RDO Release Announcement Message-ID: If you're having trouble with the formatting, this release announcement is available online https://blogs.rdoproject.org/2020/11/rdo-victoria-released/ --- RDO Victoria Released The RDO community is pleased to announce the general availability of the RDO build for OpenStack Victoria for RPM-based distributions, CentOS Linux and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Victoria is the 22nd release from the OpenStack project, which is the work of more than 1,000 contributors from around the world. The release is already available on the CentOS mirror network at http://mirror.centos.org/centos/8/cloud/x86_64/openstack-victoria/. The RDO community project curates, packages, builds, tests and maintains a complete OpenStack component set for RHEL and CentOS Linux and is a member of the CentOS Cloud Infrastructure SIG. The Cloud Infrastructure SIG focuses on delivering a great user experience for CentOS Linux users looking to build and maintain their own on-premise, public or hybrid clouds. All work on RDO and on the downstream release, Red Hat OpenStack Platform, is 100% open source, with all code changes going upstream first. PLEASE NOTE: RDO Victoria provides packages for CentOS8 and python 3 only. Please use the Train release, for CentOS7 and python 2.7. Interesting things in the Victoria release include: - With the Victoria release, source tarballs are validated using the upstream GPG signature. This certifies that the source is identical to what is released upstream and ensures the integrity of the packaged source code. - With the Victoria release, openvswitch/ovn are not shipped as part of RDO. Instead RDO relies on builds from the CentOS NFV SIG. - Some new packages have been added to RDO during the Victoria release: - ansible-collections-openstack: This package includes OpenStack modules and plugins which are supported by the OpenStack community to help with the management of OpenStack infrastructure. - ansible-tripleo-ipa-server: This package contains Ansible for configuring the FreeIPA server for TripleO. - python-ibmcclient: This package contains the python library to communicate with HUAWEI iBMC based systems. - puppet-powerflex: This package contains the puppet module needed to deploy PowerFlex with TripleO. - The following packages have been retired from the RDO OpenStack distribution in the Victoria release: - The Congress project, an open policy framework for the cloud, has been retired upstream and from the RDO project in the Victoria release. - neutron-fwaas, the Firewall as a Service driver for neutron, is no longer maintained and has been removed from RDO. Other highlights of the broader upstream OpenStack project may be read via https://releases.openstack.org/victoria/highlights. Contributors During the Victoria cycle, we saw the following new RDO contributors: Amy Marrich (spotz) Daniel Pawlik Douglas Mendizábal Lance Bragstad Martin Chacon Piza Paul Leimer Pooja Jadhav Qianbiao NG Rajini Karthik Sandeep Yadav Sergii Golovatiuk Steve Baker Welcome to all of you and Thank You So Much for participating! But we wouldn’t want to overlook anyone. A super massive Thank You to all 58 contributors who participated in producing this release. This list includes commits to rdo-packages, rdo-infra, and redhat-website repositories: Adam Kimball Ade Lee Alan Pevec Alex Schultz Alfredo Moralejo Amol Kahat Amy Marrich (spotz) Arx Cruz Bhagyashri Shewale Bogdan Dobrelya Cédric Jeanneret Chandan Kumar Damien Ciabrini Daniel Pawlik Dmitry Tantsur Douglas Mendizábal Emilien Macchi Eric Harney Francesco Pantano Gabriele Cerami Gael Chamoulaud Gorka Eguileor Grzegorz Grasza Harald Jensås Iury Gregory Melo Ferreira Jakub Libosvar Javier Pena Joel Capitao Jon Schlueter Lance Bragstad Lon Hohberger Luigi Toscano Marios Andreou Martin Chacon Piza Mathieu Bultel Matthias Runge Michele Baldessari Mike Turek Nicolas Hicher Paul Leimer Pooja Jadhav Qianbiao.NG Rabi Mishra Rafael Folco Rain Leander Rajini Karthik Riccardo Pittau Ronelle Landy Sagi Shnaidman Sandeep Yadav Sergii Golovatiuk Slawek Kaplonski Soniya Vyas Sorin Sbarnea Steve Baker Tobias Urdin Wes Hayutin Yatin Karel The Next Release Cycle At the end of one release, focus shifts immediately to the next release i.e Wallaby. Get Started There are three ways to get started with RDO. To spin up a proof of concept cloud, quickly, and on limited hardware, try an All-In-One Packstack installation. You can run RDO on a single node to get a feel for how it works. For a production deployment of RDO, use TripleO and you’ll be running a production cloud in short order. Finally, for those that don’t have any hardware or physical resources, there’s the OpenStack Global Passport Program. This is a collaborative effort between OpenStack public cloud providers to let you experience the freedom, performance and interoperability of open source infrastructure. You can quickly and easily gain access to OpenStack infrastructure via trial programs from participating OpenStack public cloud providers around the world. Get Help The RDO Project has our users at lists.rdoproject.org for RDO-specific users and operators. For more developer-oriented content we recommend joining the dev at lists.rdoproject.org mailing list. Remember to post a brief introduction about yourself and your RDO story. The mailing lists archives are all available at https://mail.rdoproject.org. You can also find extensive documentation on RDOproject.org. The #rdo channel on Freenode IRC is also an excellent place to find and give help. We also welcome comments and requests on the CentOS devel mailing list and the CentOS and TripleO IRC channels (#centos, #centos-devel, and #tripleo on irc.freenode.net), however we have a more focused audience within the RDO venues. Get Involved To get involved in the OpenStack RPM packaging effort, check out the RDO contribute pages, peruse the CentOS Cloud SIG page, and inhale the RDO packaging documentation. Join us in #rdo and #tripleo on the Freenode IRC network and follow us on Twitter @RDOCommunity. You can also find us on Facebook and YouTube. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cyrille.CARTIER at antemeta.fr Mon Nov 16 15:26:03 2020 From: Cyrille.CARTIER at antemeta.fr (Cyrille CARTIER) Date: Mon, 16 Nov 2020 15:26:03 +0000 Subject: Fwd: freezer In-Reply-To: References: <859b373263dd608c04fae208a89b038e1cb7efc9.camel@redhat.com> <6cb413b63f30445b9e776f0c2e0ab153@GUYMAIL02.antemeta.net> Message-ID: <122f88d476e34a8b9ee8df03ed86fb69@GUYMAIL02.antemeta.net> Hi Ali, Last week I’ve got a response in StoryBoard, thanks to Carl : « The bug is fixed in victoria, please update new version. Thanks. » My Colleague confirm that Ussuri version still have the same problem. Is it good for you with Stein ? We're going to test the Victoria version soon, I'll get back to you if it works. Thanks, Cyrille De : Ali Ebrahimpour [mailto:ali74.ebrahimpour at gmail.com] Envoyé : samedi 7 novembre 2020 08:06 À : Cyrille CARTIER ; smooney at redhat.com Objet : Re: Fwd: freezer hi Cyrille,sean thank you for attention I have this problem by requesting a backup with nova i used the ussuri version and two days ago got pull the version by opendev and had not changed and I want to try to install the Stein version with python2. Maybe it works correctly Did you find a solution for versions with python3? On Fri, Nov 6, 2020 at 12:08 PM Cyrille CARTIER > wrote: Hi Ali, Which openstack version do you use ? I have a similar problem on my Train plateform (deployed by kolla-ansible), using freezer-scheduler. There are many commit for py3 correction for Ussuri and Victoria branch, in Git repository [1]. Did you try these version? I have already post the problem on StoryBoard [2] and Launchpad [3]. -----Message d'origine----- Objet : Re: Fwd: freezer On Thu, 2020-11-05 at 12:42 +0330, Ali Ebrahimpour wrote: > hi i recently install the freezer api and i have problem with using it > if run this command: > freezer-agent --debug --action backup --nova-inst-id > a143d11d-fa27-4716-9795-e03b4e601df4 --storage local --container > /tmp/ali --backup-name test --mode nova --engine nova > --no-incremental true > --log-file a.log --consistency-check > > and freezer api doesn't work current and error with: > Engine error: a bytes-like object is required, not 'str' > Engine error: Forced stop that looks like a python 3 issue im not sure how active it still is but it looks like its an issue between text string and byte strings > > Adn attach the log > please help me ! > > thank you for attention [1]: https://opendev.org/openstack/freezer [2]: https://storyboard.openstack.org/#!/project/openstack/freezer [3]: https://bugs.launchpad.net/freezer/+bug/1901179 Cyrille -------------- next part -------------- An HTML attachment was scrubbed... URL: From whayutin at redhat.com Mon Nov 16 15:31:44 2020 From: whayutin at redhat.com (Wesley Hayutin) Date: Mon, 16 Nov 2020 08:31:44 -0700 Subject: centos-7 infra mirror issues, lp 1904418 Message-ID: Greetings, Just wanted to raise awareness of the following bug https://bugs.launchpad.net/tripleo/+bug/1904418 http://mirror.centos.org/centos/7/rt/x86_64/repodata/repomd.xml is a 404 Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From witold.bedyk at suse.com Mon Nov 16 15:33:46 2020 From: witold.bedyk at suse.com (Witek Bedyk) Date: Mon, 16 Nov 2020 16:33:46 +0100 Subject: [monasca] Predictive Analytics In-Reply-To: References: Message-ID: <13e5a638-f031-d64d-0cdf-188316f986b1@suse.com> Hi Giacomo, the maintainers' employee had decided to stop investing in monasca-analytics [1] and left the project. As the component requires specific knowledge which we don't have in the team and we failed to find anyone willing to maintain the repository, we decided to stop the development. The HEAD~1 commit contains the last state of the code with documentation and some use cases. Cheers Witek [1] https://opendev.org/openstack/monasca-analytics On 11/16/20 11:23 AM, Giacomo Lanciano wrote: > Hi all, > > I am new to this community, as I have only recently started using > OpenStack in my research. I am working on designing an "intelligent" > auto-scaling mechanism, based on resources consumption metrics > forecasts, leveraging on Monasca for metrics ingestion and processing. > > Digging into the Wiki/Documentation, I have stumbled upon the recently > retired "monasca-analytics", that seems to cover pretty much (and way > more of) what I had in mind to build on top of the monitoring component, > to enable proactive auto-scaling decisions. I am very interested in > knowing more about why such project has been abandoned and, more > importantly, whether the effort has been redirected to another project > that I am not aware of. > > Could you point me to any resource that you consider useful to > contribute on these topics? > > Thanks in advance. Kind Regards. > > Giacomo > From mnaser at vexxhost.com Mon Nov 16 15:45:04 2020 From: mnaser at vexxhost.com (Mohammed Naser) Date: Mon, 16 Nov 2020 10:45:04 -0500 Subject: [Freezer][Keystone][Mistral][Monasca][Murano][Openstack-Chef][Openstack-Helm][Openstacksdk][Trove][Watcher][Zun] Action required: Gerrit code audit Message-ID: Hello there, As per the `service-announce` on October 20 regarding Gerrit Outage Update email http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html, all project teams are required to audit changes for projects from 2020-10-01 to 2020-10-21. I'm reaching out to those projects in particular who the TC believes have not completed their audit yet. Let us know if you need any type of assistance in completing the audit. In case you didn’t know you needed to do this, feel free to reach out for support. Regards, Mohammed -- Mohammed Naser VEXXHOST, Inc. From james at openstack.org Mon Nov 16 17:21:22 2020 From: james at openstack.org (James Cole) Date: Mon, 16 Nov 2020 11:21:22 -0600 Subject: Where to send mascot graphic adjustment proposals Message-ID: Hi Michael, I’m James Cole, a graphic designer at the Open Infrastructure Foundation. Hopefully I can address some of your questions. Regarding the diagram, I’m told it is managed by Designate in their documentation. We can provide suggestions but ultimately it is up to them how they want to create those docs. You may have to get in touch with an active contributor to that project. Regarding mascot design changes, we’d need broader community input to make edits like that. The mascot designs undergo a community review process with each project when they’re created, so we’re unable to make design changes at this time. If it helps, the mark is vertically aligned with the text, not base aligned. Enlarging the crocodile will probably make it seem disproportionately large compared with other project mascots, which all follow the same design rules. Thanks for flagging the inactive email address for Anne. Would you mind providing the URL of the page you found that address? We will replace it with community at openinfra.dev as the contact email for mascots. Thanks for reaching out! James Cole Graphic Designer Open Infrastructure Foundation -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdulko at redhat.com Mon Nov 16 17:47:50 2020 From: mdulko at redhat.com (=?UTF-8?Q?Micha=C5=82?= Dulko) Date: Mon, 16 Nov 2020 18:47:50 +0100 Subject: [Freezer][Keystone][Mistral][Monasca][Murano][Openstack-Chef][Openstack-Helm][Openstacksdk][Trove][Watcher][Zun] Action required: Gerrit code audit In-Reply-To: References: Message-ID: <06cb55d696fc66df09f292871fa2ddaae06aaaec.camel@redhat.com> On Mon, 2020-11-16 at 10:45 -0500, Mohammed Naser wrote: > Hello there, > > As per the `service-announce` on October 20 regarding Gerrit Outage > Update email http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html, > all project teams are required to audit changes for projects from > 2020-10-01 to 2020-10-21. I'm reaching out to those projects in > particular who the TC believes have not completed their audit yet. IIUC Kuryr reported audit results already [1]. [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-October/018178.html > Let us know if you need any type of assistance in completing the audit. > > In case you didn’t know you needed to do this, feel free to reach out > for support. > > Regards, > Mohammed > From radoslaw.piliszek at gmail.com Mon Nov 16 19:36:23 2020 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Mon, 16 Nov 2020 20:36:23 +0100 Subject: [kolla] How to recover MariaDB if there's a controller failed to boot? In-Reply-To: References: Message-ID: On Mon, Nov 16, 2020 at 11:33 AM Eddie Yen wrote: > > Hi yoctozepto, thanks your advice. > > Perhaps need to do maraidb_recovery again once the failure node back online to prevent brain split issue. > But we'll try it if we met the same case again in the future! I would simply eradicate the container and volume on it and then redeploy. Less hassle, satisfaction guaranteed. -yoctozepto From sbaker at redhat.com Mon Nov 16 20:12:09 2020 From: sbaker at redhat.com (Steve Baker) Date: Tue, 17 Nov 2020 09:12:09 +1300 Subject: [ironic] Review session for API JSON conversion Message-ID: Due to timezones and the nature of the change series, we're doing some group scheduled review sessions of this series which converts the WSME based REST API to a JSON: https://review.opendev.org/#/q/status:open+topic:story/1651346 Discussion can happen on IRC in #ironic. The first session will be on this Tuesday, 7pm UTC, with a follow-up on Wednesday, 8am UTC. There is a calendar invite which I can add you to on request. cheers -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbragstad at gmail.com Mon Nov 16 20:44:11 2020 From: lbragstad at gmail.com (Lance Bragstad) Date: Mon, 16 Nov 2020 14:44:11 -0600 Subject: [qa][policy] Testing strategy discussion for new RBAC (new scope and default role combinations) In-Reply-To: References: <1758f922fe5.b2f4514a220341.5965440098876721164@ghanshyammann.com> Message-ID: Hey all, We met today to walk through testing approaches for secure RBAC. The meeting was hosted on bluejeans and recorded [0]. The notes are available on etherpad [1]. Below is a summary with what we talked about and introduces a plan for testing moving forward. Secure RBAC provides a framework and tooling to group and generalize authorization around common clouds users. Three scopes (system, domain, project) and three default roles (admin, member, reader) resulting in nine different personas (system-admin, system-member, system-reader, domain-admin, domain-member, domain-reader, project-admin, project-member, and project-reader) that cover the most common requests for customized policies for deployers. To implement these new personas into default policies, we need to test them. We currently have three testing approaches. The first approach is for each service to implement functional/unit protection tests in-tree. This approach doesn't have a direct dependency on keystone, making it self-contained. Instead of relying on tokens from keystone and keystonemiddleware putting authorization information into request headers, the functional tests would need to simulate that for the various personas. Each service will need to approach these tests in whatever was is best for their project, and implementations will likely be different. For example, nova's functional tests use mocked context objects to represent the various personas and expose them to underlying tests to use in functional API requests [2]. Placement uses gabbi to tests APIs, bypasses auth_token middleware, and sets the appropriate request headers to simulate what keystonemiddleware does before handing the request to oslo.context [3]. These tests are unlikely to be reused by deployers to verify functionality in an actual deployment. The second approach is to implement protection testing as tempest tests. Keystone recently experimented with this approach [4]. This approach provides robust testing and requires building out new tests using tempest plugins to verify the new policies. The tests are bypassed unless a feature flag is enabled in tempest [5]. This approach contains both positive and negative testing. It's also easier for deployers to re-use if they want to verify their deployments policies adhere to secure RBAC. The current implementation separates protection testing in tempest from tempest API testing, so there is some duplication across tests. Additionally, test run times are a concern. Keystone's tempest protection tests take about 45 minutes to run. We expect those times to be higher for services with larger APIs. The third approach is to overhaul the existing tempest tests to support the nine different personas, or at least the ones that are applicable to the tests. Ghanshyam is working on this approach with nova and tempest [6]. Like the second approach, this approach requires tempest configuration changes to tell tempest how to wire up the appropriate clients. While this approach uses tempest, it doesn't duplicate protection tests and existing API tests because we're incorporating the protection testing into the existing API tests. The downside with this approach is that most tempest tests are positive tests, so we would potentially have a large gap to fill with negative protection testing (e.g., ensuring project-readers can't delete volumes or instances). Today's goal was to find out how we can realistically test secure RBAC in Wallaby. The first and second approaches are likely the most robust, but they require a lot of code. The third approach focuses on re-usability but leaves testing gaps. The proposed solution was a combination of approach #1 and #3. Services implementing secure RBAC should work with Ghanshyam or myself to introduce the necessary tempest plumbing to wire up clients using the correct persona based on tempest configuration options. Most of this code is enacapsulated in tempest libs or clients already and just needs to be consumed in the API test base classes. Additional negative or positive testing should be done as in-tree protection tests, where the tests are responsible for mocking context objects that represent the nine personas. Once we're past the migration phase or supporting deprecated policies, we should seriously consider adding support for approach #2 by porting functional tests to formal tempest protection tests. We realize the proposed solution isn't a silver bullet. There are downsides. One of them is that protection testing will potentially be in two separate places. Conversely, it gives us a relatively low bar for converting tempest to effectively test secure RBAC without it being painfully exhaustive, and leaving developers with an option to supply additional testing as they see fit. The majority of the folks on the call were from cinder, but we also want to sit down with other groups to discuss this approach with them. Ghanshyam is going to set up a time with the neutron developers in the next couple of weeks. I'm going to follow up with cinder in a week or two to see how things are going. We'd like to adjust the current proposal as early as possible, if needed. We realize how hard it is to satisfy all testing requirements and be realistic, but how do people feel about the current proposal? Does it lower the bar such that it's realistic for Wallaby without sacrificing testing? [0] https://bluejeans.com/s/o2sMXK51m7E/ [1] https://etherpad.opendev.org/p/wallaby-secure-rbac-testing [2] https://opendev.org/openstack/nova/src/branch/master/nova/tests/unit/policies/base.py#L41-L121 [3] https://review.opendev.org/#/c/760235/2/placement/tests/functional/gabbits/aggregate-system-admin-policy.yaml at 9 [4] https://review.opendev.org/#/c/686305/\ [5] https://review.opendev.org/#/c/686305/47/keystone_tempest_plugin/config.py at 28 [6] https://review.opendev.org/#/c/740122/5 On Tue, Nov 10, 2020 at 12:50 PM Lance Bragstad wrote: > Hey folks, > > We held the meeting today and we started capturing some notes in an > etherpad [0]. Most of today's discussion was focused on introducing > context. We didn't come to a definitive answer as to which testing strategy > is best. > > We're going to have another meeting on Monday, November 16th (next Monday) > at 16:00 UTC. We're also going to use the same conferencing room Ghanshyam > sent out in the initial email [1]. > > Feel free to add thoughts to the etherpad [0] before hand. > > [0] https://etherpad.opendev.org/p/wallaby-secure-rbac-testing > [1] https://bluejeans.com/749897818 > > On Tue, Nov 3, 2020 at 1:25 PM Ghanshyam Mann > wrote: > >> Hello Everyone, >> >> To continue the discussion on how projects should test the new RBAC >> (scope as well as the new defaults combination), >> we will host a call on bluejeans on Tuesday 10th Nov 16.00 UTC. >> >> Lance has set up the room for that: https://bluejeans.com/749897818 >> >> Feel free to join if you are interested in that or would like to help >> with this effort. >> >> -gmann >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anlin.kong at gmail.com Mon Nov 16 21:36:25 2020 From: anlin.kong at gmail.com (Lingxian Kong) Date: Tue, 17 Nov 2020 10:36:25 +1300 Subject: Trove backup issue (Victoria) In-Reply-To: References: Message-ID: (adding openstack-discuss mailing list) Hi Justin, I don't think there is a backup docker image named "openstacktrove/db-backup-mysql5.0", the backup image only support 8.0 and 5.7. You can try "openstacktrove/db-backup-mysql5.7". --- Lingxian Kong Senior Software Engineer Catalyst Cloud www.catalystcloud.nz On Tue, Nov 17, 2020 at 3:26 AM Justin Anstes wrote: > Hi, > > Apologies to contact you about this issue. I'm sure it's a simple fix but > I've not been able to find much on it. > > I'm testing the current Victoria release. All setup ok just that I'm not > able to backup to Swift, with the following error: > > 404 Client Error: Not Found ("pull access denied for > openstacktrove/db-backup-mysql5.0, repository does not exist or may require > \'docker login\': denied: requested access to the resource is denied") > > It appears to require a Docker login.I've attached the full log just in > case you might need it. Many thanks if you have time to check. > > Kind regards > > Justin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anlin.kong at gmail.com Mon Nov 16 21:52:26 2020 From: anlin.kong at gmail.com (Lingxian Kong) Date: Tue, 17 Nov 2020 10:52:26 +1300 Subject: [trove] Gerrit breach and commit audit Message-ID: Background: http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html Looking back at the patches merged between 2020-10-01 and 2020-10-20, I can confirm that the trove deliverables repos look OK. --- Lingxian Kong Senior Software Engineer Catalyst Cloud www.catalystcloud.nz -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennelson11 at gmail.com Mon Nov 16 22:23:23 2020 From: kennelson11 at gmail.com (Kendall Nelson) Date: Mon, 16 Nov 2020 14:23:23 -0800 Subject: [SDK][OSC] Meeting Times In-Reply-To: References: Message-ID: Looks like we are a go for this week! If you want to join us, add your nick to the ping list at the top of the etherpad! If you have topics you'd like to discuss, add them to the agenda as well :) https://etherpad.opendev.org/p/openstacksdk-meeting-agenda -Kendall (diablo_rojo) On Thu, Nov 12, 2020 at 2:31 PM Kendall Nelson wrote: > I also created this etherpad to hold our meeting agendas: > https://etherpad.opendev.org/p/openstacksdk-meeting-agenda > > -Kendall (diablo_rojo) > > > On Thu, Nov 12, 2020 at 2:29 PM Kendall Nelson > wrote: > >> Sorry I am so slow at replying here! >> >> 14:00 UTC works for me so long as its only once a month I need to wake up >> at 6AM lol. >> >> I proposed the patch here: https://review.opendev.org/762590 >> >> -Kendall (diablo_rojo) >> >> On Thu, Oct 29, 2020 at 1:25 AM Artem Goncharov < >> artem.goncharov at gmail.com> wrote: >> >>> Thanks Kendall for starting the discussion. >>> >>> Being located in CET (UTC+1/2) I am fine going one hour earlier (14:00 >>> UTC) to have it not so late for Akihiro and avoid clash with Manila, but am >>> also flexible making it 16:00 (cancelled API-SIG). >>> >>> Maybe a doodle will help to pick the most suitable? I hope to get a bit >>> more answers from other interested parties. >>> >>> Regards, >>> Artem >>> >>> > On 29. Oct 2020, at 02:48, Akihiro Motoki wrote: >>> > >>> > Thanks for starting the thread. >>> > I agree it is a good idea to have a regular meeting even though it is >>> > less frequent. >>> > >>> > Thursday 15UTC is okay with me. >>> > 16UTC is a bit late to me as it is 1am in my local time. One hour >>> > earlier (14UTC) also works for me. >>> > >>> > Thanks, >>> > Akihiro Motoki (amotoki) >>> > >>> > On Thu, Oct 29, 2020 at 7:49 AM Kendall Nelson >>> wrote: >>> >> >>> >> Hello! >>> >> >>> >> In the PTG session today we talked about doing some sort of regular >>> meetings to kind of jump start things after the more recent lack of >>> activity. We discussed beginning with more frequent meetings (a couple >>> across the next few weeks) and then shifting to a more relaxed monthly >>> cadence. >>> >> >>> >> I propose 15:00 UTC on the third thursday of each month as our >>> monthly meeting time? If people agree, I will propose a patch :) >>> >> >>> >> As for the more frequent ones to keep the momentum from discussion >>> from this week/last week. We could use that time (15 UTC) and date >>> (Thursdays) and maybe just do them on Nov 12 and 19th to keep us moving? >>> That gives us next week to catch up/ take a breath from the last two weeks, >>> but not waiting till after the US Thanksgiving holiday. >>> >> >>> >> Let me know what you think! >>> >> >>> >> -Kendall Nelson (diablo_rojo) >>> >> >>> >> >>> >> >>> > >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From DHilsbos at performair.com Mon Nov 16 23:32:26 2020 From: DHilsbos at performair.com (DHilsbos at performair.com) Date: Mon, 16 Nov 2020 23:32:26 +0000 Subject: [neutron] Mixed VLAN / VxLAN Network Message-ID: <0670B960225633449A24709C291A52524F9AC15D@COM01.performair.local> All; We're getting ready to set up an OpenStack cloud, and I have some questions about networking. I apologize if this information if available already or if a question like this has already been asked. We intend to slot it in to a location which uses VLANs heavily. In particular, our DMZ is on a VLAN, with the subnet's gateway at our firewall. We plan to use VxLANs within OpenStack. Is it possible to make OpenStack aware of the DMZ VLAN, so that we can use it in projects? Is it possible to use the DMZ VLAN without routing through the OpenStack network node(s)? Thank you, Dominic L. Hilsbos, MBA Director - Information Technology Perform Air International Inc. DHilsbos at PerformAir.com www.PerformAir.com From emiller at genesishosting.com Tue Nov 17 00:21:23 2020 From: emiller at genesishosting.com (Eric K. Miller) Date: Mon, 16 Nov 2020 18:21:23 -0600 Subject: [neutron] Mixed VLAN / VxLAN Network In-Reply-To: <0670B960225633449A24709C291A52524F9AC15D@COM01.performair.local> References: <0670B960225633449A24709C291A52524F9AC15D@COM01.performair.local> Message-ID: <046E9C0290DD9149B106B72FC9156BEA04814B95@gmsxchsvr01.thecreation.com> Hi Dominic, > We intend to slot it in to a location which uses VLANs heavily. In particular, > our DMZ is on a VLAN, with the subnet's gateway at our firewall. We plan to > use VxLANs within OpenStack. > > Is it possible to make OpenStack aware of the DMZ VLAN, so that we can use > it in projects? Is it possible to use the DMZ VLAN without routing through the > OpenStack network node(s)? It is definitely possible. In OpenStack terms, you are looking for "Provider Networks", which can be used to bind a VLAN to OpenVSwitch directly on the respective compute node where a VM is running. Security groups can be used to provide port security at the VM's "ports" (vNICs). "Tenant Networks", in your configuration, will use VXLANs, and are typically managed by Neutron's DVR (Distributed Virtual Routing) which manages the VXLAN configuration on OpenVSwitches on each compute node. SNAT will always use a network node since the NAT table has to be consistent and is not replicated (it is an iptables configuration on the network node in a specific Linux network namespace for the tenant network). Floating IPs only work with networks marked as "external", which are provider networks that are VLAN-based. External networks are connected as the external gateway of an OpenStack router, where the router performs the 1:1 NAT function. Note that this does not work with IPv6, only IPv4, since IPv6 does not use NAT. The subnet assigned to the external network has a gateway property, which can be set to your firewall's gateway IP. Note that you can have multiple provider networks and share these network(s) with specific projects to provide access to a specific VLAN. These would be marked as "internal" networks. This provides a great way to transition VMs from VLAN-based networks to VXLAN-based networks. This has a good overview of the items I have discussed: https://superuser.openstack.org/articles/tenant-networks-vs-provider-net works-in-the-private-cloud-context/ Eric > Thank you, > > Dominic L. Hilsbos, MBA > Director - Information Technology > Perform Air International Inc. > DHilsbos at PerformAir.com > www.PerformAir.com From michaelr at catalyst.net.nz Tue Nov 17 00:56:48 2020 From: michaelr at catalyst.net.nz (Michael Richardson) Date: Tue, 17 Nov 2020 13:56:48 +1300 Subject: [neutron] Mixed VLAN / VxLAN Network In-Reply-To: <046E9C0290DD9149B106B72FC9156BEA04814B95@gmsxchsvr01.thecreation.com> References: <0670B960225633449A24709C291A52524F9AC15D@COM01.performair.local> <046E9C0290DD9149B106B72FC9156BEA04814B95@gmsxchsvr01.thecreation.com> Message-ID: On 17/11/20 1:21 pm, Eric K. Miller wrote: > Note that you can have multiple provider networks and share these > network(s) with specific projects to provide access to a specific VLAN. > These would be marked as "internal" networks. This provides a great way > to transition VMs from VLAN-based networks to VXLAN-based networks. Completely agree. An interesting curiosity in this context is metadata access -- it's worth allowing this to route via DHCP namespaces, per http://kimizhang.com/metadata-service-in-dhcp-namespace . Cheers, Michael -- Michael Richardson Catalyst Cloud 150-154 Willis Street, PO Box 11-053 Wellington New Zealand GPG: 0530 4686 F996 4E2C 5DC7 6327 5C98 5EED A30 From yasufum.o at gmail.com Tue Nov 17 02:21:17 2020 From: yasufum.o at gmail.com (Yasufumi Ogawa) Date: Tue, 17 Nov 2020 11:21:17 +0900 Subject: [tacker] Skip IRC meeting on Nov 17th Message-ID: Hi tacker team, I am not available to join IRC meeting today. I'd like to cancel the meeting because we may have no topics, the problem of functional test has resolved and no urgent patches. Thanks, Yasufumi From mrunge at matthias-runge.de Tue Nov 17 07:22:31 2020 From: mrunge at matthias-runge.de (Matthias Runge) Date: Tue, 17 Nov 2020 08:22:31 +0100 Subject: [telemetry] wallaby cycle planning session In-Reply-To: References: Message-ID: Good morning, quick reminder, if you are interested in telemetry and its future or fate, please participate in the doodle[3]. Thank you. On 12/11/2020 11:25, Matthias Runge wrote: > Hi there, > > one of the biggest challenges for the telemetry stack is currently the > state of gnocchi, which is... undefined/unfortunate/under-contributed/...? > > Telemetry started long time ago as a simple component ceilometer, which > was split into several components ceilometer, aodh, panko, and gnocchi. > Julien wrote a story about this some time ago[1]. > > There has also been an attempt to fork gnocchi back to OpenStack[2]. > > To my knowledge, the original contributors are not paid anymore to work > on gnocchi, and at the same time, moving on to do something else is > totally fine. > > However, I am not sure if we (in OpenStack Telemetry) should or could > maintain in addition to the rest of the telemetry stack a time-series > database. I'd like to discuss this during a call. > > Please select time(s) that suit you best in this poll[3]. > > If you have questions or hints, don't hesitate to contact me. > > Thank you, > Matthias > > [1] https://julien.danjou.info/lessons-from-openstack-telemetry-deflation/ > [2] https://review.opendev.org/#/c/744592/ > [3] https://doodle.com/poll/uqq328x5shr43awy > From renat.akhmerov at gmail.com Tue Nov 17 08:49:16 2020 From: renat.akhmerov at gmail.com (Renat Akhmerov) Date: Tue, 17 Nov 2020 15:49:16 +0700 Subject: =?utf-8?Q?=5BFreezer=5D=5BKeystone=5D=5BMistral=5D=5BMonasca=5D=5BMurano=5D=5BOpenstack-Chef=5D=5BOpenstack-Helm=5D=5BOpenstacksdk=5D=5BTrove=5D=5BWatcher=5D=5BZun=5D_?=Action required: Gerrit code audit In-Reply-To: <06cb55d696fc66df09f292871fa2ddaae06aaaec.camel@redhat.com> References: <06cb55d696fc66df09f292871fa2ddaae06aaaec.camel@redhat.com> Message-ID: <38ba37e4-a82c-45d1-9ef8-2f956b628d5c@Spark> Hi, No suspicious things were found in Mistral since the beginning of October as it is mentioned in the initial email. Thanks Renat Akhmerov @Nokia On 17 Nov 2020, 00:49 +0700, Michał Dulko , wrote: > On Mon, 2020-11-16 at 10:45 -0500, Mohammed Naser wrote: > > Hello there, > > > > As per the `service-announce` on October 20 regarding Gerrit Outage > > Update email http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html, > > all project teams are required to audit changes for projects from > > 2020-10-01 to 2020-10-21. I'm reaching out to those projects in > > particular who the TC believes have not completed their audit yet. > > IIUC Kuryr reported audit results already [1]. > > [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-October/018178.html > > > Let us know if you need any type of assistance in completing the audit. > > > > In case you didn’t know you needed to do this, feel free to reach out > > for support. > > > > Regards, > > Mohammed > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yves.guimard at gmail.com Tue Nov 17 08:54:28 2020 From: yves.guimard at gmail.com (Yves Gd) Date: Tue, 17 Nov 2020 09:54:28 +0100 Subject: [Heat] Fwaas v2 support Message-ID: Hi, Trying to use a HOT firewall template, I encounter this error: "ERROR: HEAT-E99001 Service neutron is not available for resource type OS::Neutron::Firewall, reason: Required extension fwaas in neutron service is not available." We use fwaas v2, is it supported by heat module on Train version? Our openstack environment is deployed by kolla (9.2.0) with fwaas enabled. I assume "yes" but would like to be sure. Sorry if it's written somewhere but I couldn't find this information. Here is a simple version producing the error: ------------------- heat_template_version: rocky resources: firewall1: type: OS::Neutron::Firewall properties: description: Test fwaas name: Test_fwaas ------------------- Regards, Yves -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramishra at redhat.com Tue Nov 17 09:26:55 2020 From: ramishra at redhat.com (Rabi Mishra) Date: Tue, 17 Nov 2020 14:56:55 +0530 Subject: [Heat] Fwaas v2 support In-Reply-To: References: Message-ID: On Tue, Nov 17, 2020 at 2:32 PM Yves Gd wrote: > Hi, > > Trying to use a HOT firewall template, I encounter this error: > "ERROR: HEAT-E99001 Service neutron is not available for resource type > OS::Neutron::Firewall, reason: Required extension fwaas in neutron service > is not available." > > We use fwaas v2, is it supported by heat module on Train version? > No it's not supported. The existing heat resources use fwaas v1 api, which has been removed from neutron in stein. So these heat resources are useless in train. Feel free to create a story and contribute. With very few contributors, we've not been able to keep up with all service api changes. > Our openstack environment is deployed by kolla (9.2.0) with fwaas enabled. > I assume "yes" but would like to be sure. > > Sorry if it's written somewhere but I couldn't find this information. > > Here is a simple version producing the error: > ------------------- > heat_template_version: rocky > resources: > firewall1: > type: OS::Neutron::Firewall > properties: > description: Test fwaas > name: Test_fwaas > ------------------- > > Regards, > Yves > -- Regards, Rabi Mishra -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Tue Nov 17 09:42:37 2020 From: skaplons at redhat.com (Slawek Kaplonski) Date: Tue, 17 Nov 2020 10:42:37 +0100 Subject: [Heat] Fwaas v2 support In-Reply-To: References: Message-ID: <20201117094237.545o6qnmj6kgcqf2@p1.localdomain> Hi, On Tue, Nov 17, 2020 at 02:56:55PM +0530, Rabi Mishra wrote: > On Tue, Nov 17, 2020 at 2:32 PM Yves Gd wrote: > > > Hi, > > > > Trying to use a HOT firewall template, I encounter this error: > > "ERROR: HEAT-E99001 Service neutron is not available for resource type > > OS::Neutron::Firewall, reason: Required extension fwaas in neutron service > > is not available." > > > > We use fwaas v2, is it supported by heat module on Train version? > > > > No it's not supported. The existing heat resources use fwaas v1 api, which > has been removed from neutron in stein. So these heat resources are useless > in train. > > Feel free to create a story and contribute. With very few contributors, > we've not been able to keep up with all service api changes. Please also note that due to lack of maintainers, we deprecated neutron-fwaas project so ussuri is last release of that project. > > > > Our openstack environment is deployed by kolla (9.2.0) with fwaas enabled. > > I assume "yes" but would like to be sure. > > > > Sorry if it's written somewhere but I couldn't find this information. > > > > Here is a simple version producing the error: > > ------------------- > > heat_template_version: rocky > > resources: > > firewall1: > > type: OS::Neutron::Firewall > > properties: > > description: Test fwaas > > name: Test_fwaas > > ------------------- > > > > Regards, > > Yves > > > > > -- > Regards, > Rabi Mishra -- Slawek Kaplonski Principal Software Engineer Red Hat From michapma at redhat.com Tue Nov 17 12:36:43 2020 From: michapma at redhat.com (Michael Chapman) Date: Tue, 17 Nov 2020 23:36:43 +1100 Subject: Where to send mascot graphic adjustment proposals In-Reply-To: References: Message-ID: Hi James On Tue, Nov 17, 2020 at 4:26 AM James Cole wrote: > Hi Michael, > > I’m James Cole, a graphic designer at the Open Infrastructure Foundation. > Hopefully I can address some of your questions. > > Regarding the diagram, I’m told it is managed by Designate in their > documentation. We can provide suggestions but ultimately it is up to them > how they want to create those docs. You may have to get in touch with an > active contributor to that project. > > I might not have explained this well, I am currently preparing an updated version of the diagram and am a Designate contributor. > Regarding mascot design changes, we’d need broader community input to make > edits like that. The mascot designs undergo a community review process > with each project when they’re created, so we’re unable to make design > changes at this time. > Can you be more specific on how the community can provide that input? Is there a repo I can propose changes against? > If it helps, the mark is vertically aligned with the text, not base > aligned. Enlarging the crocodile will probably make it seem > disproportionately large compared with other project mascots, which all > follow the same design rules. > I think what I'm saying is I don't think vertical alignment makes sense with such a strong horizontal line at the base of the logo. Maybe in the context of a group of mascots + text having all of them vertically aligned looks less strange but on its own I think it would look better aligned to the base. Ultimately if it's not possible to change this I can always use the vertical logo + text instead, but I thought I'd see if it could be improved first. > Thanks for flagging the inactive email address for Anne. Would you mind > providing the URL of the page you found that address? We will replace it > with community at openinfra.dev as the contact email for mascots. > > https://www.openstack.org/project-mascots/ right down the bottom On a related note I had a look at https://www.openstack.org/software/project-navigator/openstack-components#openstack-services and the designate entry there doesn't seem to be centered vertically and might need some attention as well. Thanks for reaching out! > Thanks for the detailed response! - Michael > > *James Cole* > Graphic Designer > Open Infrastructure Foundation > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaronzhu1121 at gmail.com Tue Nov 17 12:42:36 2020 From: aaronzhu1121 at gmail.com (Rong Zhu) Date: Tue, 17 Nov 2020 20:42:36 +0800 Subject: [Freezer][Keystone][Mistral][Monasca][Murano][Openstack-Chef][Openstack-Helm][Openstacksdk][Trove][Watcher][Zun] Action required: Gerrit code audit In-Reply-To: References: Message-ID: Hi, Sorry for the delay, I checked murano repos, nothing suspicious was seen. Mohammed Naser 于2020年11月16日 周一23:45写道： > Hello there, > > As per the `service-announce` on October 20 regarding Gerrit Outage > Update email > http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html > , > all project teams are required to audit changes for projects from > 2020-10-01 to 2020-10-21. I'm reaching out to those projects in > particular who the TC believes have not completed their audit yet. > > Let us know if you need any type of assistance in completing the audit. > > In case you didn’t know you needed to do this, feel free to reach out > for support. > > Regards, > Mohammed > > -- > Mohammed Naser > VEXXHOST, Inc. > -- Thanks, Rong Zhu -------------- next part -------------- An HTML attachment was scrubbed... URL: From victoria at vmartinezdelacruz.com Tue Nov 17 13:12:28 2020 From: victoria at vmartinezdelacruz.com (=?UTF-8?Q?Victoria_Mart=C3=ADnez_de_la_Cruz?=) Date: Tue, 17 Nov 2020 10:12:28 -0300 Subject: Failed to Create Virtual Instances for manila Service Due to neutron and nova Services In-Reply-To: References: Message-ID: Hi Ninad, Can you share your manila.conf file? I see you are deploying with the Generic Driver and you were getting errors with the DHSS option. What value you assigned to that option? Cheers, V On Sun, Nov 15, 2020 at 1:47 PM ninad jadhav wrote: > Hi, > > I am trying to deploy OpenStack, using Openstack installation guide > https://docs.openstack.org/install-guide/openstack-services.html#minimal-deployment-for-stein > . > > I am able to launch self-service instance, but during manila(shared-file > System) creation I am getting share creation error as per manila-share.log > "SSH to default NFS server (10.254.0.0/24) failed. I did all the > necessary steps required as per document provided but still not able to > create Instances. For Neutron Service I have used Linuxbridge (Networking > Option 2). > Following are the error logs and configuration file for nova and neutron > services. As per my discussion with manila developer manila.conf file > looks fine but there is an issue with minimal deploy which allows to create > virtual machine but for further manila instance creation its failing due to > 1. manila-share.log > https://gist.github.com/Ninad-cloud/8c77ccb53df26e6c32505a30c988004c > > 2. nov-log for instance > https://gist.github.com/Ninad-cloud/9129f1c25147e5ee7b874b77e591c9ad > > 2. controller - neutron all conf files > https://gist.github.com/Ninad-cloud/bb25e70007a2bd9ea0848edb081f6525 > https://gist.github.com/Ninad-cloud/61b3d357953ddaacc16a926770fbdb72 > https://gist.github.com/Ninad-cloud/624a4846157fc294bdfa59093e49fa55 > https://gist.github.com/Ninad-cloud/5bb3ad0cb9a38582a7c82816de653693 > https://gist.github.com/Ninad-cloud/7366ca93b03f4718a424352fe8ec63e8 > https://gist.github.com/Ninad-cloud/56ea190a333cbe0102b676b7de48b7ae > > 3.compute- neutron all .conf files > https://gist.github.com/Ninad-cloud/8b25f38bfcd001177b8f5857f6aacd96 > https://gist.github.com/Ninad-cloud/0fba595e3f3cce56695a3fc3c4795d3d > https://gist.github.com/Ninad-cloud/c8538c5b00ed2760163c3c73d1247145 > https://gist.github.com/Ninad-cloud/73f8bddebf032ea5a5e50023cc7808df > > 4.controller-nova .conf file > https://gist.github.com/Ninad-cloud/4ed5b009a62e9fbc5f9e32ddfb3f1e67 > 5. compute-nova .conf file > https://gist.github.com/Ninad-cloud/f21cd484dd9ad6c0befc66ba3c54457e > > regards, > Ninad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From victoria at vmartinezdelacruz.com Tue Nov 17 13:14:23 2020 From: victoria at vmartinezdelacruz.com (=?UTF-8?Q?Victoria_Mart=C3=ADnez_de_la_Cruz?=) Date: Tue, 17 Nov 2020 10:14:23 -0300 Subject: [manila][OSC] Priorities for implementing the OSC share commands In-Reply-To: <6EB02241-97BE-42D3-837F-5206956059B9@gmail.com> References: <6EB02241-97BE-42D3-837F-5206956059B9@gmail.com> Message-ID: Thanks for working on this Maari! I'll submit some reviews. I'd like to see feedback from operators as well. Cheers, V On Tue, Nov 10, 2020 at 2:22 PM Maari Tamm wrote: > Hi Everyone! > > Slowly but steady we are implementing the OpenStack Client for Manila. For > the upcoming release we are aiming to implement the following commands, in > no particular order: > > *Share Replicas:* > > openstack share replica create / delete / list / show / set / promote / > resync > *Share Replica Export Locations:* > openstack share replica export location list / show > > *Share Manage/Unmanage:* > > openstack share adopt / abandon > *Services:* > > openstack share service set / list > *Share Pools:* > openstack share pool list > > *User Messages:* > > openstack share message delete / list / show > *Availability Zones* (add support for manila): > openstack availability zone list > > *Limits* (add support for manila): > openstack limits show —absolute /—rate > > *Share Export Locations * (ready for reviews: > https://review.opendev.org/#/c/761661/)*:* > > openstack share export location list / show > *Share Snapshots patch II *(ready for reviews: > https://review.opendev.org/#/c/746458/) : > openstack share snapshot adopt / abandon > openstack share snapshot export location show / list > openstack share snapshot access create / delete / list > > To make this happen we could really use help reviewing the patches, once > proposed. As linked above, two patches are currently ready for > testing/reviews. > > We’d also very much appreciate getting some feedback on the list itself. > Are we missing something important that would be useful for operators and > should be implemented this cycle? If anyone has some commands in mind, > please do let us know! > > Mohammed Naser and Belmiro Moreira, would love to get your thoughts on > this as well! :) > > > Thanks, > Maari Tamm (IRC: maaritamm) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Tue Nov 17 13:29:13 2020 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Tue, 17 Nov 2020 14:29:13 +0100 Subject: [infra][kolla] Docker registry pull limits Message-ID: Hello Everyone, Kolla CI jobs started getting hit by Docker registry pull limits: docker.errors.APIError: 500 Server Error: Internal Server Error ("toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit") It is relatively random as the limit is seemingly per IP address. The question is how we should approach this issue. It seems Docker offers an open source plan that would lift any limits on the kolla namespace. [1] However, we are not entirely sure who should fill out the related form [2]. We believe it should be someone from the infra team but it is not clear. :/ Please share your thoughts. [1] https://www.docker.com/blog/expanded-support-for-open-source-software-projects/ [2] https://docs.google.com/forms/d/e/1FAIpQLSd11DjfgeaKSRdqp6Br85MzQQuM4igt-xmn6rmzA2StFGLndQ/viewform -yoctozepto From caihui_nj at 163.com Tue Nov 17 13:34:34 2020 From: caihui_nj at 163.com (=?UTF-8?B?Y2FpaHVpX25qQDE2My5jb20=?=) Date: Tue, 17 Nov 2020 21:34:34 +0800 (GMT+08:00) Subject: [Freezer] Gerrit breach and commit audit Message-ID: tencent_D2DB72216DDE3CD4B447F209@qq.com An HTML attachment was scrubbed... URL: From skaplons at redhat.com Tue Nov 17 13:38:57 2020 From: skaplons at redhat.com (Slawek Kaplonski) Date: Tue, 17 Nov 2020 14:38:57 +0100 Subject: [neutron] Team meetings today Message-ID: <1954310.xBvuYAOnJd@p1> Hi, Just a quick reminder that we have neutron team meeting today at 14:00 UTC and neutron CI meeting at 15:00 UTC. Both are on the #openstack-meetings-3 channel. Agenda for the meetings: https://wiki.openstack.org/wiki/Network/Meetings https://etherpad.opendev.org/p/neutron-ci-meetings -- Slawek Kaplonski Principal Software Engineer Red Hat From caihui_nj at 163.com Tue Nov 17 13:39:52 2020 From: caihui_nj at 163.com (=?UTF-8?B?Y2FpaHVpX25qQDE2My5jb20=?=) Date: Tue, 17 Nov 2020 21:39:52 +0800 (GMT+08:00) Subject: [Freezer] Gerrit breach and commit audit Message-ID: tencent_C2DE719E6AAF216ACFBCFA9D@qq.com An HTML attachment was scrubbed... URL: From mnaser at vexxhost.com Tue Nov 17 14:04:37 2020 From: mnaser at vexxhost.com (Mohammed Naser) Date: Tue, 17 Nov 2020 09:04:37 -0500 Subject: [tc] weekly update Message-ID: 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. # Patches ## Open Reviews - Add Magpie charm to OpenStack charms https://review.opendev.org/762820 - Move Placement under Nova's governance https://review.opendev.org/760917 - Add Resolution of TC stance on the OpenStackClient https://review.opendev.org/759904 - Remove assert_supports-zero-downtime-upgrade tag https://review.opendev.org/761975 - Add election schedule exceptions in charter https://review.opendev.org/751941 - Clarify the requirements for supports-api-interoperability https://review.opendev.org/760562 - Propose Kendall Nelson for vice chair https://review.opendev.org/762014 ## General Changes - Select JSON to YAML goal for Wallaby cycle https://review.opendev.org/760957 - Adding reno and warnings example for JSON->YAML goal doc https://review.opendev.org/760956 - Add danms liaison preferences https://review.opendev.org/758822 - Add goal for migrate RBAC policy format from JSON to YAML https://review.opendev.org/759881 - Add diablo_rojo liaison preferences https://review.opendev.org/759718 - Add ricolin liaison preferences https://review.opendev.org/759704 - Add gmann liaison preference https://review.opendev.org/758602 - Resetting projects' TC liaisons empty https://review.opendev.org/758600 Thanks for reading! Mohammed & Kendall -- Mohammed Naser VEXXHOST, Inc. From knikolla at bu.edu Tue Nov 17 14:18:34 2020 From: knikolla at bu.edu (Kristi Nikolla) Date: Tue, 17 Nov 2020 09:18:34 -0500 Subject: [Freezer][Keystone][Mistral][Monasca][Murano][Openstack-Chef][Openstack-Helm][Openstacksdk][Trove][Watcher][Zun] Action required: Gerrit code audit In-Reply-To: References: Message-ID: Nothing suspicious on keystone repos. Best, Kristi On Mon, Nov 16, 2020 at 10:46 AM Mohammed Naser wrote: > > Hello there, > > As per the `service-announce` on October 20 regarding Gerrit Outage > Update email http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html, > all project teams are required to audit changes for projects from > 2020-10-01 to 2020-10-21. I'm reaching out to those projects in > particular who the TC believes have not completed their audit yet. > > Let us know if you need any type of assistance in completing the audit. > > In case you didn’t know you needed to do this, feel free to reach out > for support. > > Regards, > Mohammed > > -- > Mohammed Naser > VEXXHOST, Inc. From lance at osuosl.org Mon Nov 16 20:13:44 2020 From: lance at osuosl.org (Lance Albertson) Date: Mon, 16 Nov 2020 12:13:44 -0800 Subject: [Freezer][Keystone][Mistral][Monasca][Murano][Openstack-Chef][Openstack-Helm][Openstacksdk][Trove][Watcher][Zun] Action required: Gerrit code audit In-Reply-To: References: Message-ID: I just went over the Chef repos and they all look good to me. Thanks for reaching out! On Mon, Nov 16, 2020 at 8:16 AM Mohammed Naser wrote: > Hello there, > > As per the `service-announce` on October 20 regarding Gerrit Outage > Update email > http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html > , > all project teams are required to audit changes for projects from > 2020-10-01 to 2020-10-21. I'm reaching out to those projects in > particular who the TC believes have not completed their audit yet. > > Let us know if you need any type of assistance in completing the audit. > > In case you didn’t know you needed to do this, feel free to reach out > for support. > > Regards, > Mohammed > > -- > Mohammed Naser > VEXXHOST, Inc. > > -- Lance Albertson Director Oregon State University | Open Source Lab -------------- next part -------------- An HTML attachment was scrubbed... URL: From kira034 at 163.com Tue Nov 17 15:21:12 2020 From: kira034 at 163.com (Hongbin Lu) Date: Tue, 17 Nov 2020 23:21:12 +0800 (GMT+08:00) Subject: [Freezer][Keystone][Mistral][Monasca][Murano][Openstack-Chef][Openstack-Helm][Openstacksdk][Trove][Watcher][Zun] Action required: Gerrit code audit In-Reply-To: References: Message-ID: <262f528a.6023.175d6cba6a5.Coremail.kira034@163.com> Nothing wrong in zun repos. | | Hongbin Lu | | Email:kira034 at 163.com | Signature is customized by Netease Mail Master On 11/17/2020 00:09, Mohammed Naser wrote: Hello there, As per the `service-announce` on October 20 regarding Gerrit Outage Update email http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html, all project teams are required to audit changes for projects from 2020-10-01 to 2020-10-21. I'm reaching out to those projects in particular who the TC believes have not completed their audit yet. Let us know if you need any type of assistance in completing the audit. In case you didn’t know you needed to do this, feel free to reach out for support. Regards, Mohammed -- Mohammed Naser VEXXHOST, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjoen at dds.nl Tue Nov 17 16:23:36 2020 From: tjoen at dds.nl (tjoen) Date: Tue, 17 Nov 2020 17:23:36 +0100 Subject: [Victoria][Python-3.9] dhcp-agent problem Message-ID: <15aeb07f-cc51-4a0a-9c28-2550caeb9ae2@dds.nl> System: LFS. Python-3.9.0, Neutron-17.0.0, oslo.privsep-2.4.0 Got Train+Py37, Usuri+Py38 working with the help of the install-guide. Victoria+Py39 Only eventlet needed a patch. Neutron only for neutron/plugins/ml2/drivers/linuxbridge/agent/arp_protect.py  def ebtables(comm, table='nat'):      execute = ip_lib.IPWrapper(NAMESPACE).netns.execute -    return execute(['ebtables', '-t', table, '--concurrent'] + comm, +    return execute(['/usr/sbin/ebtables', '-t', table, '--concurrent'] + comm,                     run_as_root=True) Possible not necessary but it avoids sudo errors. Controller logs (made readable): [-] Unable to enable dhcp for cb7948eb-e5c0-4764-a653-542c3e864f54.:    TypeError: () takes 6 positional arguments but 7 were given Traceback (most recent call last):   File "/site-packages/neutron/agent/dhcp/agent.py", line 192, in call_driver    rv = getattr(driver, action)(**action_kwargs)   File "/site-packages/neutron/agent/linux/dhcp.py", line 249, in enable    common_utils.wait_until_true(self._enable, timeout=300)   File "/site-packages/neutron/common/utils.py", line 703, in wait_until_true     while not predicate():   File "/site-packages/neutron/agent/linux/dhcp.py", line 261, in _enable     interface_name = self.device_manager.setup(self.network)   File "/site-packages/neutron/agent/linux/dhcp.py", line 1675, in setup     if ip_lib.ensure_device_is_ready(interface_name,   File "/site-packages/neutron/agent/linux/ip_lib.py", line 960,          in ensure_device_is_ready     if not dev.link.exists or not dev.link.address:   File "/site-packages/neutron/agent/linux/ip_lib.py", line 513, in exists     return privileged.interface_exists(self.name, self._parent.namespace)   File "/site-packages/oslo_privsep/priv_context.py", line 247, in _wrap     return self.channel.remote_call(name, args, kwargs)   File "/site-packages/oslo_privsep/daemon.py", line 224, in remote_call     raise exc_type(*result[2]) TypeError: () takes 6 positional arguments but 7 were given Launching an instance: $ openstack server create --flavor m1.nano --image cirros \   --nic net-id=cb7948eb-e5c0-4764-a653-542c3e864f54 --security-group default \   --key-name mykey provider-instance results in status=BUILD and never ACTIVE Other logs on Controller after starting Compute1: Unable to access   /var/lib/neutron/dhcp/cb7948eb-e5c0-4764-a653-542c3e864f54/pid;   Error: [Errno 2] No such file or directory Ownerships and permissions are OK: drwxr-xr-x 2 neutron neutron 4096 Nov 15 19:49         cb7948eb-e5c0-4764-a653-542c3e864f54/ Anybody with the same problem? I am not a Python programmer so I am at a lost From iurygregory at gmail.com Tue Nov 17 17:27:52 2020 From: iurygregory at gmail.com (Iury Gregory) Date: Tue, 17 Nov 2020 18:27:52 +0100 Subject: [Victoria][Python-3.9] dhcp-agent problem In-Reply-To: <15aeb07f-cc51-4a0a-9c28-2550caeb9ae2@dds.nl> References: <15aeb07f-cc51-4a0a-9c28-2550caeb9ae2@dds.nl> Message-ID: Hi tjoen, Victoria release doesn't support Python3.9, the maximum python version is 3.8 (default for ubuntu focal). See https://governance.openstack.org/tc/reference/runtimes/victoria.html Em ter., 17 de nov. de 2020 às 17:25, tjoen escreveu: > System: LFS. Python-3.9.0, Neutron-17.0.0, oslo.privsep-2.4.0 > > Got Train+Py37, Usuri+Py38 working with the help of the install-guide. > Victoria+Py39 Only eventlet needed a patch. > Neutron only for > neutron/plugins/ml2/drivers/linuxbridge/agent/arp_protect.py > def ebtables(comm, table='nat'): > execute = ip_lib.IPWrapper(NAMESPACE).netns.execute > - return execute(['ebtables', '-t', table, '--concurrent'] + comm, > + return execute(['/usr/sbin/ebtables', '-t', table, '--concurrent'] > + comm, > run_as_root=True) > Possible not necessary but it avoids sudo errors. > > Controller logs (made readable): > [-] Unable to enable dhcp for cb7948eb-e5c0-4764-a653-542c3e864f54.: > TypeError: () takes 6 positional arguments but 7 were given > Traceback (most recent call last): > File "/site-packages/neutron/agent/dhcp/agent.py", line 192, in > call_driver > rv = getattr(driver, action)(**action_kwargs) > File "/site-packages/neutron/agent/linux/dhcp.py", line 249, in enable > common_utils.wait_until_true(self._enable, timeout=300) > File "/site-packages/neutron/common/utils.py", line 703, in > wait_until_true > while not predicate(): > File "/site-packages/neutron/agent/linux/dhcp.py", line 261, in _enable > interface_name = self.device_manager.setup(self.network) > File "/site-packages/neutron/agent/linux/dhcp.py", line 1675, in setup > if ip_lib.ensure_device_is_ready(interface_name, > File "/site-packages/neutron/agent/linux/ip_lib.py", line 960, > in ensure_device_is_ready > if not dev.link.exists or not dev.link.address: > File "/site-packages/neutron/agent/linux/ip_lib.py", line 513, in exists > return privileged.interface_exists(self.name, self._parent.namespace) > File "/site-packages/oslo_privsep/priv_context.py", line 247, in _wrap > return self.channel.remote_call(name, args, kwargs) > File "/site-packages/oslo_privsep/daemon.py", line 224, in remote_call > raise exc_type(*result[2]) > > TypeError: () takes 6 positional arguments but 7 were given > > Launching an instance: > $ openstack server create --flavor m1.nano --image cirros \ > --nic net-id=cb7948eb-e5c0-4764-a653-542c3e864f54 --security-group > default \ > --key-name mykey provider-instance > results in status=BUILD and never ACTIVE > > Other logs on Controller after starting Compute1: > Unable to access > /var/lib/neutron/dhcp/cb7948eb-e5c0-4764-a653-542c3e864f54/pid; > Error: [Errno 2] No such file or directory > > Ownerships and permissions are OK: > drwxr-xr-x 2 neutron neutron 4096 Nov 15 19:49 > cb7948eb-e5c0-4764-a653-542c3e864f54/ > > Anybody with the same problem? > I am not a Python programmer so I am at a lost > > > -- *Att[]'sIury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Part of the puppet-manager-core team in OpenStack* *Software Engineer at Red Hat Czech* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory at gmail.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at openstack.org Tue Nov 17 17:30:15 2020 From: james at openstack.org (James Cole) Date: Tue, 17 Nov 2020 11:30:15 -0600 Subject: Where to send mascot graphic adjustment proposals In-Reply-To: References: Message-ID: Hey Michael, I asked around and doesn’t look like we've previously been asked to edit a mascot after it’s initial creation, so there’s no specific process in place currently. You’re blazing a new trail here! We definitely want to gather consensus from project contributors before making changes. The best way to do that would be the openstack-discuss mailing list with [designate] in the subject line of any messages—as documented here . Adding the tag should help other designate contributors notice and respond with their input. If you can gather consensus there, you would then email community at openinfra.dev regarding the change. So the process would be: propose change via mailing lists => gather consensus => contact the foundation. And thanks again for flagging the broken email address and the alignment issue on the page. Hope this helps! -James > On Nov 17, 2020, at 6:36 AM, Michael Chapman wrote: > > Hi James > > On Tue, Nov 17, 2020 at 4:26 AM James Cole > wrote: > Hi Michael, > > I’m James Cole, a graphic designer at the Open Infrastructure Foundation. Hopefully I can address some of your questions. > > Regarding the diagram, I’m told it is managed by Designate in their documentation. We can provide suggestions but ultimately it is up to them how they want to create those docs. You may have to get in touch with an active contributor to that project. > > > I might not have explained this well, I am currently preparing an updated version of the diagram and am a Designate contributor. > > Regarding mascot design changes, we’d need broader community input to make edits like that. The mascot designs undergo a community review process with each project when they’re created, so we’re unable to make design changes at this time. > > Can you be more specific on how the community can provide that input? Is there a repo I can propose changes against? > > > If it helps, the mark is vertically aligned with the text, not base aligned. Enlarging the crocodile will probably make it seem disproportionately large compared with other project mascots, which all follow the same design rules. > > I think what I'm saying is I don't think vertical alignment makes sense with such a strong horizontal line at the base of the logo. Maybe in the context of a group of mascots + text having all of them vertically aligned looks less strange but on its own I think it would look better aligned to the base. > > Ultimately if it's not possible to change this I can always use the vertical logo + text instead, but I thought I'd see if it could be improved first. > > > Thanks for flagging the inactive email address for Anne. Would you mind providing the URL of the page you found that address? We will replace it with community at openinfra.dev as the contact email for mascots. > > https://www.openstack.org/project-mascots/ right down the bottom > > On a related note I had a look at https://www.openstack.org/software/project-navigator/openstack-components#openstack-services and the designate entry there doesn't seem to be centered vertically and might need some attention as well. > > Thanks for reaching out! > > > Thanks for the detailed response! > > - Michael > > > James Cole > Graphic Designer > Open Infrastructure Foundation > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepa.kr at fingent.com Tue Nov 17 17:42:13 2020 From: deepa.kr at fingent.com (Deepa KR) Date: Tue, 17 Nov 2020 23:12:13 +0530 Subject: [Ussuri] Auto shutdown VM Message-ID:  Hi All We have a Openstack setup with the Ussuri Version and I am regularly facing auto shutdown of a few VMs (ubuntu16.04) randomly . If I restart then the instance is back . From logs I was able to see the messages below . WARNING nova.compute.manager [req-2a21d455-ac04-44aa-b248-4776e5109013 813f3fb52c434e38991bb90aa4771541 10b5279cb6f64ca19871f132a2cee1a3 - default default] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Received unexpected event network-vif-unplugged-e97839a1-bbc4-4d26-af30-768ca3630ce9 for instance with vm_state active and task_state None. INFO nova.compute.manager [-] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] VM Stopped (Lifecycle Event) INFO nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] During _sync_instance_power_state the DB power_state (1) does not match the vm_power_state from the hypervisor (4). Updating power_state in the DB to match the hypervisor. syslog:Nov 13 07:01:07 fgshwbucehyp04 nova-compute[2680204]: 2020-11-13 07:01:07.684 2680204 WARNING nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance shutdown by itself. Calling the stop API. Current vm_state: active, current task_state: None, original DB power_state: 1, current VM power_state: 4 nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance is already powered off in the hypervisor when stop is called. nova.virt.libvirt.driver [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance already shutdown. nova.virt.libvirt.driver [-] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance destroyed successfully. nova.compute.manager [req-7a0a0d03-e286-42f0-9e36-38a432f236f3 d9ca03b9d0884d51a26a39b6c82f02eb 304d859c43df4de4944ca5623f7f455c - default default] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Get console output nova.virt.libvirt.driver [-] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance destroyed successfully. I searched a few blogs and forums but couldn't find a solution to it . Few mentioned to add sync_power_state_interval=-1 in /etc/nova/nova.conf .But understood that this will help only when nova stops vm. But in this case vm itself is shutting down (Instance shutdown by itself. Calling the stop API) Also no memory issue in VM nor the hypervisor. Also did apt-get upgrade . It would be great if anyone can shed light to this issue. Regards, Deepa K R Sent from my iPhone -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjoen at dds.nl Tue Nov 17 17:51:14 2020 From: tjoen at dds.nl (tjoen) Date: Tue, 17 Nov 2020 18:51:14 +0100 Subject: [Victoria][Python-3.9] dhcp-agent problem In-Reply-To: References: <15aeb07f-cc51-4a0a-9c28-2550caeb9ae2@dds.nl> Message-ID: <11b01e03-55a5-6700-828a-c9620ac612d5@dds.nl> On 11/17/20 6:27 PM, Iury Gregory wrote: > Victoria release doesn't support Python3.9, the maximum python version > is 3.8 (default for ubuntu focal). /Too bad. Just converted everything to 3.9/ /Only Openstack as the last one. I am willing to participate in testing / From mnaser at vexxhost.com Tue Nov 17 18:05:29 2020 From: mnaser at vexxhost.com (Mohammed Naser) Date: Tue, 17 Nov 2020 13:05:29 -0500 Subject: [Ussuri] Auto shutdown VM In-Reply-To: References: Message-ID: On Tue, Nov 17, 2020 at 12:46 PM Deepa KR wrote: > >  Hi All > > We have a Openstack setup with the Ussuri Version and I am regularly facing auto shutdown of a few VMs (ubuntu16.04) randomly . > If I restart then the instance is back . > > From logs I was able to see the messages below . > > WARNING nova.compute.manager [req-2a21d455-ac04-44aa-b248-4776e5109013 813f3fb52c434e38991bb90aa4771541 10b5279cb6f64ca19871f132a2cee1a3 - default default] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Received unexpected event network-vif-unplugged-e97839a1-bbc4-4d26-af30-768ca3630ce9 for instance with vm_state active and task_state None. > INFO nova.compute.manager [-] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] VM Stopped (Lifecycle Event) > INFO nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] During _sync_instance_power_state the DB power_state (1) does not match the vm_power_state from the hypervisor (4). Updating power_state in the DB to match the hypervisor. > syslog:Nov 13 07:01:07 fgshwbucehyp04 nova-compute[2680204]: 2020-11-13 07:01:07.684 2680204 WARNING nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance shutdown by itself. Calling the stop API. Current vm_state: active, current task_state: None, original DB power_state: 1, current VM power_state: 4 > nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance is already powered off in the hypervisor when stop is called. > nova.virt.libvirt.driver [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance already shutdown. > nova.virt.libvirt.driver [-] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance destroyed successfully. > nova.compute.manager [req-7a0a0d03-e286-42f0-9e36-38a432f236f3 d9ca03b9d0884d51a26a39b6c82f02eb 304d859c43df4de4944ca5623f7f455c - default default] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Get console output > nova.virt.libvirt.driver [-] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance destroyed successfully. > > I searched a few blogs and forums but couldn't find a solution to it . > > Few mentioned to add sync_power_state_interval=-1 in /etc/nova/nova.conf .But understood that this will help only when nova stops vm. > But in this case vm itself is shutting down (Instance shutdown by itself. Calling the stop API) > Also no memory issue in VM nor the hypervisor. > Also did apt-get upgrade . > > It would be great if anyone can shed light to this issue. You should check and see if there is anything inside `dmesg` that shows the VM dying (any segfaults?). Also, it's possible that the VM itself is shutting off so maybe you should check ni its logs. > Regards, > Deepa K R > > Sent from my iPhone -- Mohammed Naser VEXXHOST, Inc. From iurygregory at gmail.com Tue Nov 17 18:16:49 2020 From: iurygregory at gmail.com (Iury Gregory) Date: Tue, 17 Nov 2020 19:16:49 +0100 Subject: [Victoria][Python-3.9] dhcp-agent problem In-Reply-To: <11b01e03-55a5-6700-828a-c9620ac612d5@dds.nl> References: <15aeb07f-cc51-4a0a-9c28-2550caeb9ae2@dds.nl> <11b01e03-55a5-6700-828a-c9620ac612d5@dds.nl> Message-ID: I think the plan to support Python3.9 is after Wallaby (I'm not 100% sure, maybe someone from the TC would have a better answer for when the projects should be compatible with py39) =) Em ter., 17 de nov. de 2020 às 18:52, tjoen escreveu: > > On 11/17/20 6:27 PM, Iury Gregory wrote: > > Victoria release doesn't support Python3.9, the maximum python version > > is 3.8 (default for ubuntu focal). > > /Too bad. Just converted everything to 3.9/ > > /Only Openstack as the last one. I am willing to participate in testing > / > > > -- *Att[]'sIury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Part of the puppet-manager-core team in OpenStack* *Software Engineer at Red Hat Czech* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory at gmail.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Tue Nov 17 18:17:01 2020 From: hberaud at redhat.com (Herve Beraud) Date: Tue, 17 Nov 2020 19:17:01 +0100 Subject: [release][masakari] - [Release-job-failures] Release of openstack/masakari-monitors for ref refs/tags/(7.0.1|8.0.2|9.0.1) failed In-Reply-To: References: <175c2233af9.b29635e9169357.6116747736664219007@ghanshyammann.com> Message-ID: To close this topic, masakari-monitors's refs have been reenqueued and successfully released on PyPi: - https://pypi.org/project/masakari-monitors/9.0.1/ - https://pypi.org/project/masakari-monitors/8.0.2/ - https://pypi.org/project/masakari-monitors/7.0.1/ Also notice that monasca-agent's transition to stein-em was successfully done https://review.opendev.org/#/c/762402/ The clean up of pti-python-tarball and python-branch-tarball helped us to fix the issue ( https://review.opendev.org/#/c/762699/ ). Thanks to everyone who helped us on this topic. Le ven. 13 nov. 2020 à 16:55, Herve Beraud a écrit : > Notice that this patch will face the same error too > https://review.opendev.org/#/c/762402/2 > > I'm going to hold this one until a fix is merged on the project side. > Don't forget to update the sha when the issue is fixed. > > Le ven. 13 nov. 2020 à 16:04, Ghanshyam Mann a > écrit : > >> ---- On Fri, 13 Nov 2020 06:45:54 -0600 Herve Beraud >> wrote ---- >> > >> > >> > Le ven. 13 nov. 2020 à 13:17, Radosław Piliszek < >> radoslaw.piliszek at gmail.com> a écrit : >> > On Fri, Nov 13, 2020 at 12:09 PM Herve Beraud >> wrote: >> > > >> > > Thanks for the heads up. >> > > >> > > Notice that I just submitted a series of patches [1] to fix all >> masakari's stable branches, feel free to abandon these patches if they >> aren't needed anymore. >> > > >> > > [1] >> https://review.opendev.org/#/q/topic:fix-libvirt-focal+(status:open+OR+status:merged) >> > > >> > >> > Ah, sorry, did not notice that. >> > I just went with [1] removing the pkg to avoid the naming issue >> altogether. >> > >> > No problem >> > >> > My question is whether we could detect such issues more proactively? >> > >> > Good question... I don't think that this kind of a check should be >> hosted on the release management side.Here our issue is more an environment >> issue, It's due to the fact that we decided to run the job >> `publish-openstack-artifacts` on ubuntu-focal, so to detect this kind of >> issue early I think that jobs on the projects side should rely on >> ubuntu-focal too. I'm not a Zuul expert and I don't know if it is possible >> to add a condition based on the branches (per example) to choose the right >> env (focal or not). By following this way I guess it could be possible to >> fail early on the project side, and it could allow you to fix this kind of >> issue well before proposing a new release. In other words, if projects's >> jobs env are aligned with release management our job we could catch them >> early. >> >> `publish-openstack-artifacts` job should not run for Focal for the >> stable gate and running it on Focal from Victoria onwards (like all other >> common jobs). >> >> -gmann >> >> >> > We have other scenarios to consider. These are when no patches haven't >> been merged since a while on projects side, and where a release is >> proposed, in this case even if environments are aligned, in this case we >> aren't able to detect this kind of issue, and they will continue to occur >> during publication, as in this case. >> > It could be worth it to involve the infra team to see how to fail >> early. >> > Thoughts? >> > >> > >> > [1] https://review.opendev.org/762637 >> > >> > -yoctozepto >> > >> > >> > >> > -- >> > Hervé BeraudSenior Software Engineer at Red Hatirc: hberaudhttps:// >> github.com/4383/https://twitter.com/4383hberaud >> > -----BEGIN PGP SIGNATURE----- >> > >> > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ >> > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ >> > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP >> > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G >> > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g >> > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw >> > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ >> > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 >> > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y >> > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 >> > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O >> > v6rDpkeNksZ9fFSyoY2o >> > =ECSj >> > -----END PGP SIGNATURE----- >> > >> > >> >> > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Tue Nov 17 18:18:16 2020 From: hberaud at redhat.com (Herve Beraud) Date: Tue, 17 Nov 2020 19:18:16 +0100 Subject: [release][infra] Discrepancy between release jobs and the "normal" jobs CI in terms of distro In-Reply-To: <20201113181805.wwwlhkqxalbrrbxz@yuggoth.org> References: <20201113172044.c6cgt7rdy6m6mkeu@yuggoth.org> <20201113181805.wwwlhkqxalbrrbxz@yuggoth.org> Message-ID: I confirm that these changes fixed our issue, thanks! Le ven. 13 nov. 2020 à 19:21, Jeremy Stanley a écrit : > On 2020-11-13 17:20:44 +0000 (+0000), Jeremy Stanley wrote: > [...] > > Honestly, I think the real problem here is that we have a bunch of > > unnecessary cruft in the release-openstack-python job held over > > from when we used to use tox to create release artifacts. If you > > look through the log of a successful build you'll see that we're > > not actually running tox or installing the projects being > > released, but we're using the ensure-tox and bindep roles anyway. > [...] > > This solution has been proposed: https://review.opendev.org/762699 > -- > Jeremy Stanley > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Tue Nov 17 18:27:32 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 17 Nov 2020 18:27:32 +0000 Subject: [Victoria][Python-3.9] dhcp-agent problem In-Reply-To: References: <15aeb07f-cc51-4a0a-9c28-2550caeb9ae2@dds.nl> <11b01e03-55a5-6700-828a-c9620ac612d5@dds.nl> Message-ID: <20201117182731.3ciwa5nonftx6dcl@yuggoth.org> On 2020-11-17 19:16:49 +0100 (+0100), Iury Gregory wrote: > I think the plan to support Python3.9 is after Wallaby (I'm not 100% sure, > maybe someone from the TC would have a better answer for when the projects > should be compatible with py39) [...] https://governance.openstack.org/tc/reference/runtimes/wallaby.html Yes it looks like for now the latest Python version Wallaby is targeting is 3.8 since that's the default Python version in the latest Ubuntu LTS, but there has been work done on adding (initially non-voting) 3.9 jobs to the default set run on official OpenStack deliverables: https://review.opendev.org/758813 https://review.opendev.org/760932 -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From peter.matulis at canonical.com Tue Nov 17 19:45:17 2020 From: peter.matulis at canonical.com (Peter Matulis) Date: Tue, 17 Nov 2020 14:45:17 -0500 Subject: [docs] HTTP redirects Message-ID: Hi, So I followed instructions [1] to implement redirects and it's not working. Please let me know where I went wrong: https://review.opendev.org/#/c/763067/ Shouldn't the first URL redirect to the second? https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/config-openstack.html https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/configure-openstack.html Thanks, Peter [1]: https://docs.openstack.org/doc-contrib-guide/redirects.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjoen at dds.nl Tue Nov 17 20:01:31 2020 From: tjoen at dds.nl (tjoen) Date: Tue, 17 Nov 2020 21:01:31 +0100 Subject: [Victoria][Python-3.9] dhcp-agent problem In-Reply-To: <20201117182731.3ciwa5nonftx6dcl@yuggoth.org> References: <15aeb07f-cc51-4a0a-9c28-2550caeb9ae2@dds.nl> <11b01e03-55a5-6700-828a-c9620ac612d5@dds.nl> <20201117182731.3ciwa5nonftx6dcl@yuggoth.org> Message-ID: <40120eb7-e46a-09eb-e612-1fea2c16388f@dds.nl> On 11/17/20 7:27 PM, Jeremy Stanley wrote: > but there has been work done on adding (initially > non-voting) 3.9 jobs to the default set run on official OpenStack > deliverables: > > https://review.opendev.org/758813 > https://review.opendev.org/76093 That looks promising. Up to Walaby. Forget  Victoria From doug at doughellmann.com Tue Nov 17 20:11:45 2020 From: doug at doughellmann.com (Doug Hellmann) Date: Tue, 17 Nov 2020 15:11:45 -0500 Subject: [docs] HTTP redirects In-Reply-To: References: Message-ID: > On Nov 17, 2020, at 2:45 PM, Peter Matulis wrote: > > Hi, > > So I followed instructions [1] to implement redirects and it's not working. Please let me know where I went wrong: > > https://review.opendev.org/#/c/763067/ > > Shouldn't the first URL redirect to the second? > > https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/config-openstack.html > https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/configure-openstack.html > > Thanks, > Peter > > [1]: https://docs.openstack.org/doc-contrib-guide/redirects.html You’ve followed the steps to put the redirects in your repo, but not to enable redirects for the published project. You need to edit https://opendev.org/openstack/openstack-manuals/src/branch/master/www/project-data/latest.yaml#L859 as described in https://docs.openstack.org/doc-contrib-guide/redirects.html#enable-detailed-redirects-for-your-project It is also possible that the redirect rules that have been added in the patch you linked to won’t do what you expect. All of the other example redirects use the full path from the root of docs.openstack.org . Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Tue Nov 17 20:27:04 2020 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Tue, 17 Nov 2020 21:27:04 +0100 Subject: [cinder] Ceph, active-active and no coordination Message-ID: Dear Cinder Masters, I have a question for you. (or two, or several; well, actually the whole Kolla team has :-) ) The background is that Kolla has been happily deploying multinode cinder-volume with Ceph RBD backend, with no coordination configured, cluster parameter unset, host properly set per host and backend_host normalised (as well as any other relevant config) between the cinder-volume hosts. The first question is: do we correctly understand that this was an active-active deployment? Or really something else? Now, there have been no reports that it misbehaved for anyone. It certainly has not for any Kolla core. The fact is it was brought to our attention because due to the drop of Kolla-deployed Ceph, the recommendation to set backend_host was not present and users tripped over non-uniform backend_host. And this is expected, of course. The second and final question is, building up on the first one, were we doing it wrong all the time? (plus extras: Why did it work? Were there any quirks? What should we do?) PS: Please let me know if this thought process is actually Ceph-independent as well. -yoctozepto From gfidente at redhat.com Tue Nov 17 21:03:10 2020 From: gfidente at redhat.com (Giulio Fidente) Date: Tue, 17 Nov 2020 22:03:10 +0100 Subject: [cinder] Ceph, active-active and no coordination In-Reply-To: References: Message-ID: I am leaving some comments inline and adding on CC some cinder folks who know better On 11/17/20 9:27 PM, Radosław Piliszek wrote: > Dear Cinder Masters, > > I have a question for you. (or two, or several; well, actually the > whole Kolla team has :-) ) > > The background is that Kolla has been happily deploying multinode > cinder-volume with Ceph RBD backend, with no coordination configured, > cluster parameter unset, host properly set per host and backend_host > normalised (as well as any other relevant config) between the > cinder-volume hosts. > > The first question is: do we correctly understand that this was an > active-active deployment? Or really something else? this configuration is similar to that deployed by tripleo, except tripleo would use pacemaker to have always a single cinder-volume running the reason being that, as far as I understand, without a coordinator the first cinder-volume within a given 'backend_host' group to consume the message from the amqp queue will start executing the task ... so if another task is queued (or is in progress), for the same volume, there is risk of data corruption > Now, there have been no reports that it misbehaved for anyone. It > certainly has not for any Kolla core. The fact is it was brought to > our attention because due to the drop of Kolla-deployed Ceph, the > recommendation to set backend_host was not present and users tripped > over non-uniform backend_host. And this is expected, of course. > > The second and final question is, building up on the first one, were > we doing it wrong all the time? > (plus extras: Why did it work? Were there any quirks? What should we do?) I think the correct setup for active/active should be - do not use same host or backend_host - do set cluster to same value across cluster members - use a coordinator > PS: Please let me know if this thought process is actually > Ceph-independent as well. I don't think it's Ceph dependent, my understanding is that active/active is only possible with some drivers because not every driver is safe to use in active/active configuration; some can, for example, have issues handling the database Ceph is just one of those drivers which behaves correctly in active/active configuration -- Giulio Fidente GPG KEY: 08D733BA From deepa.kr at fingent.com Wed Nov 18 02:43:18 2020 From: deepa.kr at fingent.com (Deepa KR) Date: Wed, 18 Nov 2020 08:13:18 +0530 Subject: [Ussuri] Auto shutdown VM In-Reply-To: References: Message-ID: <9A9C606C-3658-473C-83DC-6305D496A6CD@fingent.com> Hello Mohammed Thanks for the response. No error message inside vm. Have checked dmesg, syslog etc . I mentioned vm is shutting down itself because of error messages Instance shutdown by itself. Calling the stop API. Current vm_state: active, current task_state: None, original DB power_state: 1, current VM power_state: 4 from hypervisor. Sent from my iPhone > On 17-Nov-2020, at 11:35 PM, Mohammed Naser wrote: > > On Tue, Nov 17, 2020 at 12:46 PM Deepa KR wrote: >> >>  Hi All >> >> We have a Openstack setup with the Ussuri Version and I am regularly facing auto shutdown of a few VMs (ubuntu16.04) randomly . >> If I restart then the instance is back . >> >> From logs I was able to see the messages below . >> >> WARNING nova.compute.manager [req-2a21d455-ac04-44aa-b248-4776e5109013 813f3fb52c434e38991bb90aa4771541 10b5279cb6f64ca19871f132a2cee1a3 - default default] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Received unexpected event network-vif-unplugged-e97839a1-bbc4-4d26-af30-768ca3630ce9 for instance with vm_state active and task_state None. >> INFO nova.compute.manager [-] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] VM Stopped (Lifecycle Event) >> INFO nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] During _sync_instance_power_state the DB power_state (1) does not match the vm_power_state from the hypervisor (4). Updating power_state in the DB to match the hypervisor. >> syslog:Nov 13 07:01:07 fgshwbucehyp04 nova-compute[2680204]: 2020-11-13 07:01:07.684 2680204 WARNING nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance shutdown by itself. Calling the stop API. Current vm_state: active, current task_state: None, original DB power_state: 1, current VM power_state: 4 >> nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance is already powered off in the hypervisor when stop is called. >> nova.virt.libvirt.driver [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance already shutdown. >> nova.virt.libvirt.driver [-] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance destroyed successfully. >> nova.compute.manager [req-7a0a0d03-e286-42f0-9e36-38a432f236f3 d9ca03b9d0884d51a26a39b6c82f02eb 304d859c43df4de4944ca5623f7f455c - default default] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Get console output >> nova.virt.libvirt.driver [-] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance destroyed successfully. >> >> I searched a few blogs and forums but couldn't find a solution to it . >> >> Few mentioned to add sync_power_state_interval=-1 in /etc/nova/nova.conf .But understood that this will help only when nova stops vm. >> But in this case vm itself is shutting down (Instance shutdown by itself. Calling the stop API) >> Also no memory issue in VM nor the hypervisor. >> Also did apt-get upgrade . >> >> It would be great if anyone can shed light to this issue. > > You should check and see if there is anything inside `dmesg` that > shows the VM dying (any segfaults?). Also, it's possible that the VM > itself is shutting off so maybe you should check ni its logs. > >> Regards, >> Deepa K R >> >> Sent from my iPhone > > > > -- > Mohammed Naser > VEXXHOST, Inc. From mnaser at vexxhost.com Wed Nov 18 03:27:15 2020 From: mnaser at vexxhost.com (Mohammed Naser) Date: Tue, 17 Nov 2020 22:27:15 -0500 Subject: [Ussuri] Auto shutdown VM In-Reply-To: <9A9C606C-3658-473C-83DC-6305D496A6CD@fingent.com> References: <9A9C606C-3658-473C-83DC-6305D496A6CD@fingent.com> Message-ID: On Tue, Nov 17, 2020 at 9:43 PM Deepa KR wrote: > Hello Mohammed > > Thanks for the response. > No error message inside vm. Have checked dmesg, syslog etc . > > I mentioned vm is shutting down itself because of error messages Instance > shutdown by itself. Calling the stop API. Current vm_state: active, current > task_state: None, original DB power_state: 1, current VM power_state: 4 > from hypervisor. This really doesn’t mean that the VM is shutting itself down. This just means that Nova has noticed that the power state of the VM doesn’t match the database one. You would also see this error message in any scenario where the VM disappeared from libvirt > > Sent from my iPhone > > > On 17-Nov-2020, at 11:35 PM, Mohammed Naser wrote: > > > > On Tue, Nov 17, 2020 at 12:46 PM Deepa KR wrote: > >> > >>  Hi All > >> > >> We have a Openstack setup with the Ussuri Version and I am regularly > facing auto shutdown of a few VMs (ubuntu16.04) randomly . > >> If I restart then the instance is back . > >> > >> From logs I was able to see the messages below . > >> > >> WARNING nova.compute.manager [req-2a21d455-ac04-44aa-b248-4776e5109013 > 813f3fb52c434e38991bb90aa4771541 10b5279cb6f64ca19871f132a2cee1a3 - default > default] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Received > unexpected event network-vif-unplugged-e97839a1-bbc4-4d26-af30-768ca3630ce9 > for instance with vm_state active and task_state None. > >> INFO nova.compute.manager [-] [instance: > 28cd861c-ef15-444a-a902-9cac643c72b5] VM Stopped (Lifecycle Event) > >> INFO nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - > - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] During > _sync_instance_power_state the DB power_state (1) does not match the > vm_power_state from the hypervisor (4). Updating power_state in the DB to > match the hypervisor. > >> syslog:Nov 13 07:01:07 fgshwbucehyp04 nova-compute[2680204]: 2020-11-13 > 07:01:07.684 2680204 WARNING nova.compute.manager > [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: > 28cd861c-ef15-444a-a902-9cac643c72b5] Instance shutdown by itself. Calling > the stop API. Current vm_state: active, current task_state: None, original > DB power_state: 1, current VM power_state: 4 > >> nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - > -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance is already > powered off in the hypervisor when stop is called. > >> nova.virt.libvirt.driver [req-8261f607-4f1e-459d-85d4-e269694dd477 - - > - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance already > shutdown. > >> nova.virt.libvirt.driver [-] [instance: > 28cd861c-ef15-444a-a902-9cac643c72b5] Instance destroyed successfully. > >> nova.compute.manager [req-7a0a0d03-e286-42f0-9e36-38a432f236f3 > d9ca03b9d0884d51a26a39b6c82f02eb 304d859c43df4de4944ca5623f7f455c - default > default] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Get console output > >> nova.virt.libvirt.driver [-] [instance: > 28cd861c-ef15-444a-a902-9cac643c72b5] Instance destroyed successfully. > >> > >> I searched a few blogs and forums but couldn't find a solution to it . > >> > >> Few mentioned to add sync_power_state_interval=-1 in > /etc/nova/nova.conf .But understood that this will help only when nova > stops vm. > >> But in this case vm itself is shutting down (Instance shutdown by > itself. Calling the stop API) > >> Also no memory issue in VM nor the hypervisor. > >> Also did apt-get upgrade . > >> > >> It would be great if anyone can shed light to this issue. > > > > You should check and see if there is anything inside `dmesg` that > > shows the VM dying (any segfaults?). Also, it's possible that the VM > > itself is shutting off so maybe you should check ni its logs. > > > >> Regards, > >> Deepa K R > >> > >> Sent from my iPhone > > > > > > > > -- > > Mohammed Naser > > VEXXHOST, Inc. > -- Mohammed Naser VEXXHOST, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepa.kr at fingent.com Wed Nov 18 04:53:24 2020 From: deepa.kr at fingent.com (Deepa KR) Date: Wed, 18 Nov 2020 10:23:24 +0530 Subject: [Ussuri] Auto shutdown VM In-Reply-To: References: Message-ID: <6DF5F056-7965-4F4F-BEFF-4EF84CA77A9A@fingent.com> Thanks for the response. Any idea what would have caused power state to mismatch in DB. Hypervisors qemu versions are upto date. We have many VMs and seeing this issue with only few VMs(say 3) Sent from my iPhone > On 18-Nov-2020, at 8:57 AM, Mohammed Naser wrote: > > This really doesn’t mean that the VM is shutting itself down. This just means that Nova has noticed that the power state of the VM doesn’t match the database one. > > You would also see this error message in any scenario where the VM disappeared from libvirt From ignaziocassano at gmail.com Wed Nov 18 06:16:03 2020 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Wed, 18 Nov 2020 07:16:03 +0100 Subject: [stein][neutron] gratuitous arp In-Reply-To: <7de015a7292674b4ed5aa4926f01de760d133de9.camel@redhat.com> References: <9ac105e8b7176ecc085f57ec84d891afa927c637.camel@redhat.com> <7de015a7292674b4ed5aa4926f01de760d133de9.camel@redhat.com> Message-ID: Hello, I tried to update to last stein packages on yum and seems this bug still exists. Before the yum update I patched some files as suggested and and ping to vm worked fine. After yum update the issue returns. Please, let me know If I must patch files by hand or some new parameters in configuration can solve and/or the issue is solved in newer openstack versions. Thanks Ignazio Il Mer 29 Apr 2020, 19:49 Sean Mooney ha scritto: > On Wed, 2020-04-29 at 17:10 +0200, Ignazio Cassano wrote: > > Many thanks. > > Please keep in touch. > here are the two patches. > the first https://review.opendev.org/#/c/724386/ is the actual change to > add the new config opition > this needs a release note and some tests but it shoudl be functional hence > the [WIP] > i have not enable the workaround in any job in this patch so the ci run > will assert this does not break > anything in the default case > > the second patch is https://review.opendev.org/#/c/724387/ which enables > the workaround in the multi node ci jobs > and is testing that live migration exctra works when the workaround is > enabled. > > this should work as it is what we expect to happen if you are using a > moderne nova with an old neutron. > its is marked [DNM] as i dont intend that patch to merge but if the > workaround is useful we migth consider enableing > it for one of the jobs to get ci coverage but not all of the jobs. > > i have not had time to deploy a 2 node env today but ill try and test this > locally tomorow. > > > > > Ignazio > > > > Il giorno mer 29 apr 2020 alle ore 16:55 Sean Mooney > > > ha scritto: > > > > > so bing pragmatic i think the simplest path forward given my other > patches > > > have not laned > > > in almost 2 years is to quickly add a workaround config option to > disable > > > mulitple port bindign > > > which we can backport and then we can try and work on the actual fix > after. > > > acording to https://bugs.launchpad.net/neutron/+bug/1815989 that > shoudl > > > serve as a workaround > > > for thos that hav this issue but its a regression in functionality. > > > > > > i can create a patch that will do that in an hour or so and submit a > > > followup DNM patch to enabel the > > > workaound in one of the gate jobs that tests live migration. > > > i have a meeting in 10 mins and need to finish the pacht im currently > > > updating but ill submit a poc once that is done. > > > > > > im not sure if i will be able to spend time on the actul fix which i > > > proposed last year but ill see what i can do. > > > > > > > > > On Wed, 2020-04-29 at 16:37 +0200, Ignazio Cassano wrote: > > > > PS > > > > I have testing environment on queens,rocky and stein and I can make > test > > > > as you need. > > > > Ignazio > > > > > > > > Il giorno mer 29 apr 2020 alle ore 16:19 Ignazio Cassano < > > > > ignaziocassano at gmail.com> ha scritto: > > > > > > > > > Hello Sean, > > > > > the following is the configuration on my compute nodes: > > > > > [root at podiscsivc-kvm01 network-scripts]# rpm -qa|grep libvirt > > > > > libvirt-daemon-driver-storage-iscsi-4.5.0-33.el7.x86_64 > > > > > libvirt-daemon-kvm-4.5.0-33.el7.x86_64 > > > > > libvirt-libs-4.5.0-33.el7.x86_64 > > > > > libvirt-daemon-driver-network-4.5.0-33.el7.x86_64 > > > > > libvirt-daemon-driver-nodedev-4.5.0-33.el7.x86_64 > > > > > libvirt-daemon-driver-storage-gluster-4.5.0-33.el7.x86_64 > > > > > libvirt-client-4.5.0-33.el7.x86_64 > > > > > libvirt-daemon-driver-storage-core-4.5.0-33.el7.x86_64 > > > > > libvirt-daemon-driver-storage-logical-4.5.0-33.el7.x86_64 > > > > > libvirt-daemon-driver-secret-4.5.0-33.el7.x86_64 > > > > > libvirt-daemon-4.5.0-33.el7.x86_64 > > > > > libvirt-daemon-driver-nwfilter-4.5.0-33.el7.x86_64 > > > > > libvirt-daemon-driver-storage-scsi-4.5.0-33.el7.x86_64 > > > > > libvirt-daemon-driver-storage-rbd-4.5.0-33.el7.x86_64 > > > > > libvirt-daemon-config-nwfilter-4.5.0-33.el7.x86_64 > > > > > libvirt-daemon-driver-storage-disk-4.5.0-33.el7.x86_64 > > > > > libvirt-bash-completion-4.5.0-33.el7.x86_64 > > > > > libvirt-daemon-driver-qemu-4.5.0-33.el7.x86_64 > > > > > libvirt-daemon-driver-storage-4.5.0-33.el7.x86_64 > > > > > libvirt-python-4.5.0-1.el7.x86_64 > > > > > libvirt-daemon-driver-interface-4.5.0-33.el7.x86_64 > > > > > libvirt-daemon-driver-storage-mpath-4.5.0-33.el7.x86_64 > > > > > [root at podiscsivc-kvm01 network-scripts]# rpm -qa|grep qemu > > > > > qemu-kvm-common-ev-2.12.0-44.1.el7_8.1.x86_64 > > > > > qemu-kvm-ev-2.12.0-44.1.el7_8.1.x86_64 > > > > > libvirt-daemon-driver-qemu-4.5.0-33.el7.x86_64 > > > > > centos-release-qemu-ev-1.0-4.el7.centos.noarch > > > > > ipxe-roms-qemu-20180825-2.git133f4c.el7.noarch > > > > > qemu-img-ev-2.12.0-44.1.el7_8.1.x86_64 > > > > > > > > > > > > > > > As far as firewall driver > > > > > > /etc/neutron/plugins/ml2/openvswitch_agent.ini: > > > > > > > > > > firewall_driver = iptables_hybrid > > > > > > > > > > I have same libvirt/qemu version on queens, on rocky and on stein > > > > > > testing > > > > > environment and the > > > > > same firewall driver. > > > > > Live migration on provider network on queens works fine. > > > > > It does not work fine on rocky and stein (vm lost connection after > it > > > > > > is > > > > > migrated and start to respond only when the vm send a network > packet , > > > > > > for > > > > > example when chrony pools the time server). > > > > > > > > > > Ignazio > > > > > > > > > > > > > > > > > > > > Il giorno mer 29 apr 2020 alle ore 14:36 Sean Mooney < > > > > > > smooney at redhat.com> > > > > > ha scritto: > > > > > > > > > > > On Wed, 2020-04-29 at 10:39 +0200, Ignazio Cassano wrote: > > > > > > > Hello, some updated about this issue. > > > > > > > I read someone has got same issue as reported here: > > > > > > > > > > > > > > https://bugs.launchpad.net/neutron/+bug/1866139 > > > > > > > > > > > > > > If you read the discussion, someone tells that the garp must be > > > > > > sent by > > > > > > > qemu during live miration. > > > > > > > If this is true, this means on rocky/stein the qemu/libvirt are > > > > > > bugged. > > > > > > > > > > > > it is not correct. > > > > > > qemu/libvir thas alsway used RARP which predates GARP to serve as > > > > > > its mac > > > > > > learning frames > > > > > > instead > > > > > > https://en.wikipedia.org/wiki/Reverse_Address_Resolution_Protocol > > > > > > > https://lists.gnu.org/archive/html/qemu-devel/2009-10/msg01457.html > > > > > > however it looks like this was broken in 2016 in qemu 2.6.0 > > > > > > > https://lists.gnu.org/archive/html/qemu-devel/2016-07/msg04645.html > > > > > > but was fixed by > > > > > > > > > > > > > https://github.com/qemu/qemu/commit/ca1ee3d6b546e841a1b9db413eb8fa09f13a061b > > > > > > can you confirm you are not using the broken 2.6.0 release and > are > > > > > > using > > > > > > 2.7 or newer or 2.4 and older. > > > > > > > > > > > > > > > > > > > So I tried to use stein and rocky with the same version of > > > > > > libvirt/qemu > > > > > > > packages I installed on queens (I updated compute and > controllers > > > > > > node > > > > > > > > > > > > on > > > > > > > queens for obtaining same libvirt/qemu version deployed on > rocky > > > > > > and > > > > > > > > > > > > stein). > > > > > > > > > > > > > > On queens live migration on provider network continues to work > > > > > > fine. > > > > > > > On rocky and stein not, so I think the issue is related to > > > > > > openstack > > > > > > > components . > > > > > > > > > > > > on queens we have only a singel prot binding and nova blindly > assumes > > > > > > that the port binding details wont > > > > > > change when it does a live migration and does not update the xml > for > > > > > > the > > > > > > netwrok interfaces. > > > > > > > > > > > > the port binding is updated after the migration is complete in > > > > > > post_livemigration > > > > > > in rocky+ neutron optionally uses the multiple port bindings > flow to > > > > > > prebind the port to the destiatnion > > > > > > so it can update the xml if needed and if post copy live > migration is > > > > > > enable it will asyconsly activate teh dest port > > > > > > binding before post_livemigration shortenting the downtime. > > > > > > > > > > > > if you are using the iptables firewall os-vif will have > precreated > > > > > > the > > > > > > ovs port and intermediate linux bridge before the > > > > > > migration started which will allow neutron to wire it up (put it > on > > > > > > the > > > > > > correct vlan and install security groups) before > > > > > > the vm completes the migraton. > > > > > > > > > > > > if you are using the ovs firewall os-vif still precreates teh ovs > > > > > > port > > > > > > but libvirt deletes it and recreats it too. > > > > > > as a result there is a race when using openvswitch firewall that > can > > > > > > result in the RARP packets being lost. > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > Ignazio Cassano > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Il giorno lun 27 apr 2020 alle ore 19:50 Sean Mooney < > > > > > > > > > > > > smooney at redhat.com> > > > > > > > ha scritto: > > > > > > > > > > > > > > > On Mon, 2020-04-27 at 18:19 +0200, Ignazio Cassano wrote: > > > > > > > > > Hello, I have this problem with rocky or newer with > > > > > > iptables_hybrid > > > > > > > > > firewall. > > > > > > > > > So, can I solve using post copy live migration ??? > > > > > > > > > > > > > > > > so this behavior has always been how nova worked but rocky > the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/neutron-new-port-binding-api.html > > > > > > > > spec intoduced teh ablity to shorten the outage by pre > biding the > > > > > > > > > > > > port and > > > > > > > > activating it when > > > > > > > > the vm is resumed on the destiation host before we get to pos > > > > > > live > > > > > > > > > > > > migrate. > > > > > > > > > > > > > > > > this reduces the outage time although i cant be fully > elimiated > > > > > > as > > > > > > > > > > > > some > > > > > > > > level of packet loss is > > > > > > > > always expected when you live migrate. > > > > > > > > > > > > > > > > so yes enabliy post copy live migration should help but be > aware > > > > > > that > > > > > > > > > > > > if a > > > > > > > > network partion happens > > > > > > > > during a post copy live migration the vm will crash and need > to > > > > > > be > > > > > > > > restarted. > > > > > > > > it is generally safe to use and will imporve the migration > > > > > > performace > > > > > > > > > > > > but > > > > > > > > unlike pre copy migration if > > > > > > > > the guess resumes on the dest and the mempry page has not > been > > > > > > copied > > > > > > > > > > > > yet > > > > > > > > then it must wait for it to be copied > > > > > > > > and retrive it form the souce host. if the connection too the > > > > > > souce > > > > > > > > > > > > host > > > > > > > > is intrupted then the vm cant > > > > > > > > do that and the migration will fail and the instance will > crash. > > > > > > if > > > > > > > > > > > > you > > > > > > > > are using precopy migration > > > > > > > > if there is a network partaion during the migration the > > > > > > migration will > > > > > > > > fail but the instance will continue > > > > > > > > to run on the source host. > > > > > > > > > > > > > > > > so while i would still recommend using it, i it just good to > be > > > > > > aware > > > > > > > > > > > > of > > > > > > > > that behavior change. > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > Ignazio > > > > > > > > > > > > > > > > > > Il Lun 27 Apr 2020, 17:57 Sean Mooney > ha > > > > > > > > > > > > scritto: > > > > > > > > > > > > > > > > > > > On Mon, 2020-04-27 at 17:06 +0200, Ignazio Cassano wrote: > > > > > > > > > > > Hello, I have a problem on stein neutron. When a vm > migrate > > > > > > > > > > > > from one > > > > > > > > > > > > > > > > node > > > > > > > > > > > to another I cannot ping it for several minutes. If in > the > > > > > > vm I > > > > > > > > > > > > put a > > > > > > > > > > > script that ping the gateway continously, the live > > > > > > migration > > > > > > > > > > > > works > > > > > > > > > > > > > > > > fine > > > > > > > > > > > > > > > > > > > > and > > > > > > > > > > > I can ping it. Why this happens ? I read something > about > > > > > > > > > > > > gratuitous > > > > > > > > > > > > > > > > arp. > > > > > > > > > > > > > > > > > > > > qemu does not use gratuitous arp but instead uses an > older > > > > > > > > > > > > protocal > > > > > > > > > > > > > > > > called > > > > > > > > > > RARP > > > > > > > > > > to do mac address learning. > > > > > > > > > > > > > > > > > > > > what release of openstack are you using. and are you > using > > > > > > > > > > > > iptables > > > > > > > > > > firewall of openvswitch firewall. > > > > > > > > > > > > > > > > > > > > if you are using openvswtich there is is nothing we can > do > > > > > > until > > > > > > > > > > > > we > > > > > > > > > > finally delegate vif pluging to os-vif. > > > > > > > > > > currently libvirt handels interface plugging for kernel > ovs > > > > > > when > > > > > > > > > > > > using > > > > > > > > > > > > > > > > the > > > > > > > > > > openvswitch firewall driver > > > > > > > > > > https://review.opendev.org/#/c/602432/ would adress that > > > > > > but it > > > > > > > > > > > > and > > > > > > > > > > > > > > > > the > > > > > > > > > > neutron patch are > > > > > > > > > > https://review.opendev.org/#/c/640258 rather out dated. > > > > > > while > > > > > > > > > > > > libvirt > > > > > > > > > > > > > > > > is > > > > > > > > > > pluging the vif there will always be > > > > > > > > > > a race condition where the RARP packets sent by qemu and > > > > > > then mac > > > > > > > > > > > > > > > > learning > > > > > > > > > > packets will be lost. > > > > > > > > > > > > > > > > > > > > if you are using the iptables firewall and you have > opnestack > > > > > > > > > > > > rock or > > > > > > > > > > later then if you enable post copy live migration > > > > > > > > > > it should reduce the downtime. in this conficution we do > not > > > > > > have > > > > > > > > > > > > the > > > > > > > > > > > > > > > > race > > > > > > > > > > betwen neutron and libvirt so the rarp > > > > > > > > > > packets should not be lost. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please, help me ? > > > > > > > > > > > Any workaround , please ? > > > > > > > > > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > Ignazio > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eblock at nde.ag Wed Nov 18 06:19:05 2020 From: eblock at nde.ag (Eugen Block) Date: Wed, 18 Nov 2020 06:19:05 +0000 Subject: [Ussuri] Auto shutdown VM In-Reply-To: <6DF5F056-7965-4F4F-BEFF-4EF84CA77A9A@fingent.com> References: <6DF5F056-7965-4F4F-BEFF-4EF84CA77A9A@fingent.com> Message-ID: <20201118061905.Horde.hAt2SOsPFPyufj5RYVxgMr-@webmail.nde.ag> Hi, from my own experience the mismatch happened when someone was playing with virt-manager (or other tools) to reboot/shutdown VMs through libvirt and not from inside the VM or via openstack. And since nova has to catch up at some point this led to a cycle of unwanted shutdown events. In my case I know that users were trying to do that via virt-manager, does that apply to your scenario, too? Or does libvirt show any error logs that would explain unexpected shutdowns? Regards, Eugen Zitat von Deepa KR : > Thanks for the response. > Any idea what would have caused power state to mismatch in DB. > Hypervisors qemu versions are upto date. We have many VMs and seeing > this issue with only few VMs(say 3) > > Sent from my iPhone > >> On 18-Nov-2020, at 8:57 AM, Mohammed Naser wrote: >> >> This really doesn’t mean that the VM is shutting itself down. This >> just means that Nova has noticed that the power state of the VM >> doesn’t match the database one. >> >> You would also see this error message in any scenario where the VM >> disappeared from libvirt From zhang.lei.fly+os-discuss at gmail.com Wed Nov 18 06:38:08 2020 From: zhang.lei.fly+os-discuss at gmail.com (Jeffrey Zhang) Date: Wed, 18 Nov 2020 14:38:08 +0800 Subject: [cinder] Ceph, active-active and no coordination In-Reply-To: References: Message-ID: imho, the same host(backend_host) are resolving the different issues with coordination. The same host(backend_host) makes multiple cinder-volume work in active/active mode by leveraging rabbitmq queue with multi consumers. one cinder-volume death doesn't affect anything. The coordination just prevents the same resource(image) from being accessed by multi cinder-volume or eventlet in one cinder-volume. I.e one image can not be snapshot during deleting. This is beyond active-active. So I think coordination is required for all drivers, including ceph. kolla should add this in default. On Wed, Nov 18, 2020 at 5:06 AM Giulio Fidente wrote: > I am leaving some comments inline and adding on CC some cinder folks who > know better > > On 11/17/20 9:27 PM, Radosław Piliszek wrote: > > Dear Cinder Masters, > > > > I have a question for you. (or two, or several; well, actually the > > whole Kolla team has :-) ) > > > > The background is that Kolla has been happily deploying multinode > > cinder-volume with Ceph RBD backend, with no coordination configured, > > cluster parameter unset, host properly set per host and backend_host > > normalised (as well as any other relevant config) between the > > cinder-volume hosts. > > > > The first question is: do we correctly understand that this was an > > active-active deployment? Or really something else? > > this configuration is similar to that deployed by tripleo, except > tripleo would use pacemaker to have always a single cinder-volume running > > the reason being that, as far as I understand, without a coordinator the > first cinder-volume within a given 'backend_host' group to consume the > message from the amqp queue will start executing the task ... so if > another task is queued (or is in progress), for the same volume, there > is risk of data corruption > > > Now, there have been no reports that it misbehaved for anyone. It > > certainly has not for any Kolla core. The fact is it was brought to > > our attention because due to the drop of Kolla-deployed Ceph, the > > recommendation to set backend_host was not present and users tripped > > over non-uniform backend_host. And this is expected, of course. > > > > The second and final question is, building up on the first one, were > > we doing it wrong all the time? > > (plus extras: Why did it work? Were there any quirks? What should we do?) > I think the correct setup for active/active should be > > - do not use same host or backend_host > - do set cluster to same value across cluster members > - use a coordinator > > > PS: Please let me know if this thought process is actually > > Ceph-independent as well. > I don't think it's Ceph dependent, my understanding is that > active/active is only possible with some drivers because not every > driver is safe to use in active/active configuration; some can, for > example, have issues handling the database > > Ceph is just one of those drivers which behaves correctly in > active/active configuration > -- > Giulio Fidente > GPG KEY: 08D733BA > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhang.lei.fly+os-discuss at gmail.com Wed Nov 18 06:49:01 2020 From: zhang.lei.fly+os-discuss at gmail.com (Jeffrey Zhang) Date: Wed, 18 Nov 2020 14:49:01 +0800 Subject: [kolla] How to recover MariaDB if there's a controller failed to boot? In-Reply-To: References: Message-ID: A simple handy way it 0. stop all mariadb containers 1. choose the last stopped node ( data may be loss if you choose a wrong node, but mostly, it doesn't matter) 2. change the /var/lib/docker/volumes/mariadb/_data/grastate.dat, safe_to_bootstrap: 1 3. change the /etc/kolla/mariadb/galera.cnf add ``` [mysqld] wsrep_new_cluster=1 ``` 4. start the mariadb, and wait for it to become available. 5. start mariadb on other nodes 6. revert configuration on 3) and restart the first mariadb On Tue, Nov 17, 2020 at 3:42 AM Radosław Piliszek < radoslaw.piliszek at gmail.com> wrote: > On Mon, Nov 16, 2020 at 11:33 AM Eddie Yen wrote: > > > > Hi yoctozepto, thanks your advice. > > > > Perhaps need to do maraidb_recovery again once the failure node back > online to prevent brain split issue. > > But we'll try it if we met the same case again in the future! > > I would simply eradicate the container and volume on it and then redeploy. > Less hassle, satisfaction guaranteed. > > -yoctozepto > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepa.kr at fingent.com Wed Nov 18 07:06:59 2020 From: deepa.kr at fingent.com (Deepa KR) Date: Wed, 18 Nov 2020 12:36:59 +0530 Subject: [Ussuri] Auto shutdown VM In-Reply-To: <20201118061905.Horde.hAt2SOsPFPyufj5RYVxgMr-@webmail.nde.ag> References: <20201118061905.Horde.hAt2SOsPFPyufj5RYVxgMr-@webmail.nde.ag> Message-ID: <8E9F7984-1CD3-4883-B4A4-BF96983CB56E@fingent.com> Hello Eugen Thanks for the response. I am pretty sure none was playing with virt-manager. Wil check libvirt logs and update back. Even enabled crashdump in vm which didn’t generate any at the time of vm shutdown. In qemu logs there was just one message stating “ 2020-11-13 07:00:52.164+0000: shutting down, reason=crashed” Sent from my iPhone > On 18-Nov-2020, at 11:49 AM, Eugen Block wrote: > > Hi, > > from my own experience the mismatch happened when someone was playing with virt-manager (or other tools) to reboot/shutdown VMs through libvirt and not from inside the VM or via openstack. And since nova has to catch up at some point this led to a cycle of unwanted shutdown events. In my case I know that users were trying to do that via virt-manager, does that apply to your scenario, too? Or does libvirt show any error logs that would explain unexpected shutdowns? > > Regards, > Eugen > > > Zitat von Deepa KR : > >> Thanks for the response. >> Any idea what would have caused power state to mismatch in DB. Hypervisors qemu versions are upto date. We have many VMs and seeing this issue with only few VMs(say 3) >> >> Sent from my iPhone >> >>>> On 18-Nov-2020, at 8:57 AM, Mohammed Naser wrote: >>> >>> This really doesn’t mean that the VM is shutting itself down. This just means that Nova has noticed that the power state of the VM doesn’t match the database one. >>> >>> You would also see this error message in any scenario where the VM disappeared from libvirt > > > From rui.zang at yandex.com Wed Nov 18 08:25:59 2020 From: rui.zang at yandex.com (rui zang) Date: Wed, 18 Nov 2020 16:25:59 +0800 Subject: [Ussuri] Auto shutdown VM In-Reply-To: References: Message-ID: <158621605687826@mail.yandex.com> An HTML attachment was scrubbed... URL: From missile0407 at gmail.com Wed Nov 18 08:35:42 2020 From: missile0407 at gmail.com (Eddie Yen) Date: Wed, 18 Nov 2020 16:35:42 +0800 Subject: [kolla] How to recover MariaDB if there's a controller failed to boot? In-Reply-To: References: Message-ID: Thank you Jeffery! This is also a useful information for us, too. Jeffrey Zhang 於 2020年11月18日 週三 下午2:49寫道： > A simple handy way it > > 0. stop all mariadb containers > 1. choose the last stopped node ( data may be loss if you choose a wrong > node, but mostly, it doesn't matter) > 2. change the /var/lib/docker/volumes/mariadb/_data/grastate.dat, > safe_to_bootstrap: 1 > 3. change the /etc/kolla/mariadb/galera.cnf add > ``` > [mysqld] > wsrep_new_cluster=1 > ``` > 4. start the mariadb, and wait for it to become available. > 5. start mariadb on other nodes > 6. revert configuration on 3) and restart the first mariadb > > On Tue, Nov 17, 2020 at 3:42 AM Radosław Piliszek < > radoslaw.piliszek at gmail.com> wrote: > >> On Mon, Nov 16, 2020 at 11:33 AM Eddie Yen wrote: >> > >> > Hi yoctozepto, thanks your advice. >> > >> > Perhaps need to do maraidb_recovery again once the failure node back >> online to prevent brain split issue. >> > But we'll try it if we met the same case again in the future! >> >> I would simply eradicate the container and volume on it and then redeploy. >> Less hassle, satisfaction guaranteed. >> >> -yoctozepto >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From noonedeadpunk at ya.ru Wed Nov 18 08:55:47 2020 From: noonedeadpunk at ya.ru (Dmitriy Rabotyagov) Date: Wed, 18 Nov 2020 10:55:47 +0200 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: <4211161605171577@mail.yandex.ru> Message-ID: <5971221605688542@mail.yandex.ru> An HTML attachment was scrubbed... URL: From mark at stackhpc.com Wed Nov 18 09:01:04 2020 From: mark at stackhpc.com (Mark Goddard) Date: Wed, 18 Nov 2020 09:01:04 +0000 Subject: [docs] HTTP redirects In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 at 20:12, Doug Hellmann wrote: > > > > On Nov 17, 2020, at 2:45 PM, Peter Matulis wrote: > > Hi, > > So I followed instructions [1] to implement redirects and it's not working. Please let me know where I went wrong: > > https://review.opendev.org/#/c/763067/ > > Shouldn't the first URL redirect to the second? > > https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/config-openstack.html > https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/configure-openstack.html FWIW, here's a patch that adds redirects for Kayobe: https://review.opendev.org/#/c/748523/ Mark > > Thanks, > Peter > > [1]: https://docs.openstack.org/doc-contrib-guide/redirects.html > > > You’ve followed the steps to put the redirects in your repo, but not to enable redirects for the published project. > > You need to edit https://opendev.org/openstack/openstack-manuals/src/branch/master/www/project-data/latest.yaml#L859 as described in https://docs.openstack.org/doc-contrib-guide/redirects.html#enable-detailed-redirects-for-your-project > > It is also possible that the redirect rules that have been added in the patch you linked to won’t do what you expect. All of the other example redirects use the full path from the root of docs.openstack.org. > > Doug > From mark at stackhpc.com Wed Nov 18 09:30:31 2020 From: mark at stackhpc.com (Mark Goddard) Date: Wed, 18 Nov 2020 09:30:31 +0000 Subject: [cinder] Ceph, active-active and no coordination In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 at 20:27, Radosław Piliszek wrote: > > Dear Cinder Masters, > > I have a question for you. (or two, or several; well, actually the > whole Kolla team has :-) ) Thanks for kicking off this thread, Radek. > > The background is that Kolla has been happily deploying multinode > cinder-volume with Ceph RBD backend, with no coordination configured, > cluster parameter unset, host properly set per host and backend_host > normalised (as well as any other relevant config) between the > cinder-volume hosts. > > The first question is: do we correctly understand that this was an > active-active deployment? Or really something else? > > Now, there have been no reports that it misbehaved for anyone. It > certainly has not for any Kolla core. The fact is it was brought to > our attention because due to the drop of Kolla-deployed Ceph, the > recommendation to set backend_host was not present and users tripped > over non-uniform backend_host. And this is expected, of course. Here is the bug report [1]. It relates to using an externally deployed Ceph cluster, rather than one deployed via Kolla Ansible. To provide a little more background, in Train and earlier releases we documented to set backend_host. From Ussuri, we automated more of the Ceph configuration, and in the process dropped backend_host. It's not clear why. Users upgrading to Ussuri from Train, and dropping their custom Cinder config in favour of the Kolla automation would lose backend_host, and therefore volumes would become unmanageable. A manual step is required to move them to one of the cinder-volume hosts. That bug caused us to question the active/active setup, especially after finding a related OSA bug [2]. I can't find any Cinder admin guide for active/active configuration, although there is a high level spec [3] (with linked sub-specs) and some contributor docs [4] that outline the various problems. [1] https://bugs.launchpad.net/kolla-ansible/+bug/1904062 [2] https://bugs.launchpad.net/openstack-ansible/+bug/1837403 [3] https://specs.openstack.org/openstack/cinder-specs/specs/mitaka/cinder-volume-active-active-support.html [4] https://docs.openstack.org/cinder/latest/contributor/high_availability.html > > The second and final question is, building up on the first one, were > we doing it wrong all the time? > (plus extras: Why did it work? Were there any quirks? What should we do?) > > PS: Please let me know if this thought process is actually > Ceph-independent as well. > > -yoctozepto > From geguileo at redhat.com Wed Nov 18 09:32:59 2020 From: geguileo at redhat.com (Gorka Eguileor) Date: Wed, 18 Nov 2020 10:32:59 +0100 Subject: [cinder] Ceph, active-active and no coordination In-Reply-To: References: Message-ID: <20201118093259.k6hjbjfbc6eomymg@localhost> On 17/11, Giulio Fidente wrote: > I am leaving some comments inline and adding on CC some cinder folks who > know better > > On 11/17/20 9:27 PM, Radosław Piliszek wrote: > > Dear Cinder Masters, > > > > I have a question for you. (or two, or several; well, actually the > > whole Kolla team has :-) ) > > > > The background is that Kolla has been happily deploying multinode > > cinder-volume with Ceph RBD backend, with no coordination configured, > > cluster parameter unset, host properly set per host and backend_host > > normalised (as well as any other relevant config) between the > > cinder-volume hosts. > > > > The first question is: do we correctly understand that this was an > > active-active deployment? Or really something else? Hi, That is an Active-Active deployment with an Active-Passive configuration, so it's a PROBLEM waiting to happen. Besides races that could happen in the code because there is no coordinator configured (this is less of an issue for the RBD driver than for other drivers, but it's still an issue), there's also a problem whenever a cinder-volume service starts. Any time a cinder-volume service starts it will mess many of the resources that are being worked on (those with status ending in 'ing', such as 'creating') because it thinks those are resources that it left in that state and need to be cleaned. My recommendation is to do this right: configure the cluster option, remove the backend_host, and configure the coordinator. Upgrading a deployment from that configuration to clustered is relatively easy, we just need to leave one of the cinder-volume services with the backend_host as it was before; that way when it starts it will automatically migrate all the resources from being non-clustered to being clustered (an alternative would be to add this command to cinder-manage, because I don't think the current "cinder-manage cluster rename" will work). If deploying the coordinator is an issue, we should at least do the other 2 steps. That way we'll get rid of the cleanup issue even if we still have the race conditions. Cheers, Gorka. > > this configuration is similar to that deployed by tripleo, except > tripleo would use pacemaker to have always a single cinder-volume running > > the reason being that, as far as I understand, without a coordinator the > first cinder-volume within a given 'backend_host' group to consume the > message from the amqp queue will start executing the task ... so if > another task is queued (or is in progress), for the same volume, there > is risk of data corruption > > > Now, there have been no reports that it misbehaved for anyone. It > > certainly has not for any Kolla core. The fact is it was brought to > > our attention because due to the drop of Kolla-deployed Ceph, the > > recommendation to set backend_host was not present and users tripped > > over non-uniform backend_host. And this is expected, of course. > > > > The second and final question is, building up on the first one, were > > we doing it wrong all the time? > > (plus extras: Why did it work? Were there any quirks? What should we do?) > I think the correct setup for active/active should be > > - do not use same host or backend_host > - do set cluster to same value across cluster members > - use a coordinator > > > PS: Please let me know if this thought process is actually > > Ceph-independent as well. > I don't think it's Ceph dependent, my understanding is that > active/active is only possible with some drivers because not every > driver is safe to use in active/active configuration; some can, for > example, have issues handling the database > > Ceph is just one of those drivers which behaves correctly in > active/active configuration > -- > Giulio Fidente > GPG KEY: 08D733BA > From ignaziocassano at gmail.com Wed Nov 18 09:40:03 2020 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Wed, 18 Nov 2020 10:40:03 +0100 Subject: [stein][cinder][iscsi] multipath does not seem to detach during live migration Message-ID: Hello Everyone, I am testing stein with cinder iscsi driver for unity. Since I became crazy on queens, I decided to try with stein. At this time I have only one virtual machine with only one iscsi volume. It was running on podiscsivc-kvm02 and I migrated it on podiscsivc-kvm01. Let me show what multipath -ll displays on podiscsivc-kvm02 after live migration: 36006016006e04400dce5b45f0ac77301 dm-3 DGC ,VRAID size=40G features='1 retain_attached_hw_handler' hwhandler='1 alua' wp=rw |-+- policy='round-robin 0' prio=0 status=active | `- 17:0:0:60 sdm 8:192 failed faulty running `-+- policy='round-robin 0' prio=0 status=enabled |- 19:0:0:60 sdk 8:160 failed faulty running `- 21:0:0:60 sdj 8:144 failed faulty running And now on destination node podiscsivc-kvm01: 36006016006e04400dce5b45f0ac77301 dm-3 DGC ,VRAID size=40G features='2 queue_if_no_path retain_attached_hw_handler' hwhandler='1 alua' wp=rw |-+- policy='round-robin 0' prio=50 status=active | |- 17:0:0:14 sdm 8:192 active ready running | `- 15:0:0:14 sdl 8:176 active ready running `-+- policy='round-robin 0' prio=10 status=enabled |- 21:0:0:14 sdj 8:144 active ready running `- 19:0:0:14 sdk 8:160 active ready running On source node in /var/log/messages I get: Nov 18 10:34:19 podiscsivc-kvm02 multipathd: 36006016006e04400dce5b45f0ac77301: failed in domap for addition of new path sdl Nov 18 10:34:19 podiscsivc-kvm02 multipathd: 36006016006e04400dce5b45f0ac77301: uev_add_path sleep Nov 18 10:34:20 podiscsivc-kvm02 multipathd: 36006016006e04400dce5b45f0ac77301: failed in domap for addition of new path sdl Nov 18 10:34:20 podiscsivc-kvm02 kernel: device-mapper: table: 253:3: multipath: error getting device Nov 18 10:34:20 podiscsivc-kvm02 kernel: device-mapper: ioctl: error adding target to table Nov 18 10:34:20 podiscsivc-kvm02 multipathd: 36006016006e04400dce5b45f0ac77301: uev_add_path sleep On storage node seems it wotks fine, because the host access migrated from source to destination node. Multipath.conf is the following: blacklist { # Skip the files uner /dev that are definitely not FC/iSCSI devices # Different system may need different customization devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*" devnode "^hd[a-z][0-9]*" devnode "^cciss!c[0-9]d[0-9]*[p[0-9]*]" # Skip LUNZ device from VNX/Unity device { vendor "DGC" product "LUNZ" } } defaults { user_friendly_names no flush_on_last_del yes remove_retries 12 skip_kpartx yes } devices { # Device attributed for EMC CLARiiON and VNX/Unity series ALUA device { vendor "DGC" product ".*" product_blacklist "LUNZ" path_grouping_policy group_by_prio path_selector "round-robin 0" path_checker emc_clariion features "0" no_path_retry 12 hardware_handler "1 alua" prio alua failback immediate } } Why it leaves failed faulty running devices ? Is it a correct behaviour ? I contacted Dell support and they said it is not an a problem of their cinder driver but ti could be related to nova. Please help me !!! I must decide if acquire nfs storage or iscsi storage. On the cinder compatibility drive matrix most vendors are iscsi. Ignazio -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Wed Nov 18 10:11:55 2020 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Wed, 18 Nov 2020 11:11:55 +0100 Subject: [stein][cinder][iscsi] multipath does not seem to detach during live migration In-Reply-To: References: Message-ID: Hello, I add further information: every time I migrate my single instance from a node to another the number of files under /dev/disk/by-path increase of 4 (the number of path used for unity storage) on the destination node. Ignazio Il giorno mer 18 nov 2020 alle ore 10:40 Ignazio Cassano < ignaziocassano at gmail.com> ha scritto: > Hello Everyone, > I am testing stein with cinder iscsi driver for unity. > Since I became crazy on queens, I decided to try with stein. > At this time I have only one virtual machine with only one iscsi volume. > > It was running on podiscsivc-kvm02 and I migrated it on podiscsivc-kvm01. > > Let me show what multipath -ll displays on podiscsivc-kvm02 after live > migration: > > 36006016006e04400dce5b45f0ac77301 dm-3 DGC ,VRAID > size=40G features='1 retain_attached_hw_handler' hwhandler='1 alua' wp=rw > |-+- policy='round-robin 0' prio=0 status=active > | `- 17:0:0:60 sdm 8:192 failed faulty running > `-+- policy='round-robin 0' prio=0 status=enabled > |- 19:0:0:60 sdk 8:160 failed faulty running > `- 21:0:0:60 sdj 8:144 failed faulty running > > And now on destination node podiscsivc-kvm01: > 36006016006e04400dce5b45f0ac77301 dm-3 DGC ,VRAID > size=40G features='2 queue_if_no_path retain_attached_hw_handler' > hwhandler='1 alua' wp=rw > |-+- policy='round-robin 0' prio=50 status=active > | |- 17:0:0:14 sdm 8:192 active ready running > | `- 15:0:0:14 sdl 8:176 active ready running > `-+- policy='round-robin 0' prio=10 status=enabled > |- 21:0:0:14 sdj 8:144 active ready running > `- 19:0:0:14 sdk 8:160 active ready running > > On source node in /var/log/messages I get: > Nov 18 10:34:19 podiscsivc-kvm02 multipathd: > 36006016006e04400dce5b45f0ac77301: failed in domap for addition of new path > sdl > Nov 18 10:34:19 podiscsivc-kvm02 multipathd: > 36006016006e04400dce5b45f0ac77301: uev_add_path sleep > Nov 18 10:34:20 podiscsivc-kvm02 multipathd: > 36006016006e04400dce5b45f0ac77301: failed in domap for addition of new path > sdl > Nov 18 10:34:20 podiscsivc-kvm02 kernel: device-mapper: table: 253:3: > multipath: error getting device > Nov 18 10:34:20 podiscsivc-kvm02 kernel: device-mapper: ioctl: error > adding target to table > Nov 18 10:34:20 podiscsivc-kvm02 multipathd: > 36006016006e04400dce5b45f0ac77301: uev_add_path sleep > > On storage node seems it wotks fine, because the host access migrated from > source to destination node. > > Multipath.conf is the following: > > blacklist { > # Skip the files uner /dev that are definitely not FC/iSCSI devices > # Different system may need different customization > devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*" > devnode "^hd[a-z][0-9]*" > devnode "^cciss!c[0-9]d[0-9]*[p[0-9]*]" > > # Skip LUNZ device from VNX/Unity > device { > vendor "DGC" > product "LUNZ" > } > } > > defaults { > user_friendly_names no > flush_on_last_del yes > remove_retries 12 > skip_kpartx yes > } > > devices { > # Device attributed for EMC CLARiiON and VNX/Unity series ALUA > device { > vendor "DGC" > product ".*" > product_blacklist "LUNZ" > path_grouping_policy group_by_prio > path_selector "round-robin 0" > path_checker emc_clariion > features "0" > no_path_retry 12 > hardware_handler "1 alua" > prio alua > failback immediate > } > } > > Why it leaves failed faulty running devices ? > Is it a correct behaviour ? > I contacted Dell support and they said it is not an a problem of their > cinder driver but ti could be related to nova. > Please help me !!! > I must decide if acquire nfs storage or iscsi storage. > On the cinder compatibility drive matrix most vendors are iscsi. > > Ignazio > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Wed Nov 18 10:38:20 2020 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Wed, 18 Nov 2020 11:38:20 +0100 Subject: [kolla] How to recover MariaDB if there's a controller failed to boot? In-Reply-To: References: Message-ID: Just to clarify. The below is what the mariadb_recovery is doing behind the scenes. No magic. :-) -yoctozepto On Wed, Nov 18, 2020 at 9:35 AM Eddie Yen wrote: > > Thank you Jeffery! This is also a useful information for us, too. > > Jeffrey Zhang 於 2020年11月18日 週三 下午2:49寫道： >> >> A simple handy way it >> >> 0. stop all mariadb containers >> 1. choose the last stopped node ( data may be loss if you choose a wrong node, but mostly, it doesn't matter) >> 2. change the /var/lib/docker/volumes/mariadb/_data/grastate.dat, safe_to_bootstrap: 1 >> 3. change the /etc/kolla/mariadb/galera.cnf add >> ``` >> [mysqld] >> wsrep_new_cluster=1 >> ``` >> 4. start the mariadb, and wait for it to become available. >> 5. start mariadb on other nodes >> 6. revert configuration on 3) and restart the first mariadb >> >> On Tue, Nov 17, 2020 at 3:42 AM Radosław Piliszek wrote: >>> >>> On Mon, Nov 16, 2020 at 11:33 AM Eddie Yen wrote: >>> > >>> > Hi yoctozepto, thanks your advice. >>> > >>> > Perhaps need to do maraidb_recovery again once the failure node back online to prevent brain split issue. >>> > But we'll try it if we met the same case again in the future! >>> >>> I would simply eradicate the container and volume on it and then redeploy. >>> Less hassle, satisfaction guaranteed. >>> >>> -yoctozepto >>> From ignaziocassano at gmail.com Wed Nov 18 11:26:38 2020 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Wed, 18 Nov 2020 12:26:38 +0100 Subject: [openstack][stein][cinder] iscsi multipath issues Message-ID: Hello Everyone, I am testing stein with cinder iscsi driver for unity. Since I became crazy on queens, I decided to try with stein. At this time I have only one virtual machine with only one iscsi volume. It was running on podiscsivc-kvm02 and I migrated it on podiscsivc-kvm01. Let me show what multipath -ll displays on podiscsivc-kvm02 after live migration: 36006016006e04400dce5b45f0ac77301 dm-3 DGC ,VRAID size=40G features='1 retain_attached_hw_handler' hwhandler='1 alua' wp=rw |-+- policy='round-robin 0' prio=0 status=active | `- 17:0:0:60 sdm 8:192 failed faulty running `-+- policy='round-robin 0' prio=0 status=enabled |- 19:0:0:60 sdk 8:160 failed faulty running `- 21:0:0:60 sdj 8:144 failed faulty running And now on destination node podiscsivc-kvm01: 36006016006e04400dce5b45f0ac77301 dm-3 DGC ,VRAID size=40G features='2 queue_if_no_path retain_attached_hw_handler' hwhandler='1 alua' wp=rw |-+- policy='round-robin 0' prio=50 status=active | |- 17:0:0:14 sdm 8:192 active ready running | `- 15:0:0:14 sdl 8:176 active ready running `-+- policy='round-robin 0' prio=10 status=enabled |- 21:0:0:14 sdj 8:144 active ready running `- 19:0:0:14 sdk 8:160 active ready running On source node in /var/log/messages I get: Nov 18 10:34:19 podiscsivc-kvm02 multipathd: 36006016006e04400dce5b45f0ac77301: failed in domap for addition of new path sdl Nov 18 10:34:19 podiscsivc-kvm02 multipathd: 36006016006e04400dce5b45f0ac77301: uev_add_path sleep Nov 18 10:34:20 podiscsivc-kvm02 multipathd: 36006016006e04400dce5b45f0ac77301: failed in domap for addition of new path sdl Nov 18 10:34:20 podiscsivc-kvm02 kernel: device-mapper: table: 253:3: multipath: error getting device Nov 18 10:34:20 podiscsivc-kvm02 kernel: device-mapper: ioctl: error adding target to table Nov 18 10:34:20 podiscsivc-kvm02 multipathd: 36006016006e04400dce5b45f0ac77301: uev_add_path sleep On storage node seems it wotks fine, because the host access migrated from source to destination node. Multipath.conf is the following: blacklist { # Skip the files uner /dev that are definitely not FC/iSCSI devices # Different system may need different customization devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*" devnode "^hd[a-z][0-9]*" devnode "^cciss!c[0-9]d[0-9]*[p[0-9]*]" # Skip LUNZ device from VNX/Unity device { vendor "DGC" product "LUNZ" } } defaults { user_friendly_names no flush_on_last_del yes remove_retries 12 skip_kpartx yes } devices { # Device attributed for EMC CLARiiON and VNX/Unity series ALUA device { vendor "DGC" product ".*" product_blacklist "LUNZ" path_grouping_policy group_by_prio path_selector "round-robin 0" path_checker emc_clariion features "0" no_path_retry 12 hardware_handler "1 alua" prio alua failback immediate } } Why it leaves failed faulty running devices ? Is it a correct behaviour ? Every time I migrate my single instance from a node to another the number of files under /dev/disk/by-path increase of 4 (the number of path used for unity storage) on the destination node. I contacted Dell support and they said it is not an a problem of their cinder driver but ti could be related to nova. Please help me !!! I must decide if acquire nfs storage or iscsi storage. On the cinder compatibility drive matrix most vendors are iscsi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepa.kr at fingent.com Wed Nov 18 11:53:27 2020 From: deepa.kr at fingent.com (Deepa KR) Date: Wed, 18 Nov 2020 17:23:27 +0530 Subject: [Ussuri] Auto shutdown VM In-Reply-To: <158621605687826@mail.yandex.com> References: <158621605687826@mail.yandex.com> Message-ID: <14800219-BC67-4B94-88CE-81FE5D8A6AB2@fingent.com> Thanks for pointing out. Have 70 + vms and has issue with just 3 vms so i am really confused Sent from my iPhone > On 18-Nov-2020, at 1:56 PM, rui zang wrote: > >  > [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Received unexpected event network-vif-unplugged-e97839a1-bbc4-4d26-af30-768ca3630ce9 for instance with vm_state active and task_state None. > > > Clearly the network virtual interface was somehow removed or unplugged. What you should look into is OVS or whatever the network solution you are using. > > > 18.11.2020, 01:44, "Deepa KR" : >  Hi All > > We have a Openstack setup with the Ussuri Version and I am regularly facing auto shutdown of a few VMs (ubuntu16.04) randomly . > If I restart then the instance is back . > > From logs I was able to see the messages below . > > WARNING nova.compute.manager [req-2a21d455-ac04-44aa-b248-4776e5109013 813f3fb52c434e38991bb90aa4771541 10b5279cb6f64ca19871f132a2cee1a3 - default default] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Received unexpected event network-vif-unplugged-e97839a1-bbc4-4d26-af30-768ca3630ce9 for instance with vm_state active and task_state None. > INFO nova.compute.manager [-] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] VM Stopped (Lifecycle Event) > INFO nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] During _sync_instance_power_state the DB power_state (1) does not match the vm_power_state from the hypervisor (4). Updating power_state in the DB to match the hypervisor. > syslog:Nov 13 07:01:07 fgshwbucehyp04 nova-compute[2680204]: 2020-11-13 07:01:07.684 2680204 WARNING nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance shutdown by itself. Calling the stop API. Current vm_state: active, current task_state: None, original DB power_state: 1, current VM power_state: 4 > nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance is already powered off in the hypervisor when stop is called. > nova.virt.libvirt.driver [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance already shutdown. > nova.virt.libvirt.driver [-] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance destroyed successfully. > nova.compute.manager [req-7a0a0d03-e286-42f0-9e36-38a432f236f3 d9ca03b9d0884d51a26a39b6c82f02eb 304d859c43df4de4944ca5623f7f455c - default default] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Get console output > nova.virt.libvirt.driver [-] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance destroyed successfully. > > I searched a few blogs and forums but couldn't find a solution to it . > > Few mentioned to add sync_power_state_interval=-1 in /etc/nova/nova.conf .But understood that this will help only when nova stops vm. > But in this case vm itself is shutting down (Instance shutdown by itself. Calling the stop API) > Also no memory issue in VM nor the hypervisor. > Also did apt-get upgrade . > > It would be great if anyone can shed light to this issue. > > Regards, > Deepa K R > > Sent from my iPhone -------------- next part -------------- An HTML attachment was scrubbed... URL: From victoria at vmartinezdelacruz.com Wed Nov 18 11:54:41 2020 From: victoria at vmartinezdelacruz.com (=?UTF-8?Q?Victoria_Mart=C3=ADnez_de_la_Cruz?=) Date: Wed, 18 Nov 2020 08:54:41 -0300 Subject: Failed to Create Virtual Instances for manila Service Due to neutron and nova Services In-Reply-To: References: Message-ID: A few things Ninad: 1. Can you SSH to other instances normally? 2. Have you checked the security groups to make sure you are enabling traffic on port 22? 3. For your use case, do you really need to use DHSS=True? DHSS=False scenarios are easier to handle and debug, so unless you have a specific reason to use DHSS=True I'd suggest you change that option. Cheers, V On Tue, Nov 17, 2020 at 2:29 PM ninad jadhav wrote: > Sure, here it is. > https://gist.github.com/Ninad-cloud/361cb5aacd4810c2fb5b4840d5af96d6 > > I don't understand why it is not allowing to SSH to 10.254.0.0/16. > > regards, > Ninad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From moguimar at redhat.com Wed Nov 18 12:55:15 2020 From: moguimar at redhat.com (Moises Guimaraes de Medeiros) Date: Wed, 18 Nov 2020 13:55:15 +0100 Subject: [oslo] following or not following the DST changes for our meeting time In-Reply-To: References: Message-ID: Hi Hervé, Historically, Oslo team meeting has been at 1500 UTC, which translates to 3PM UTC, I think the discussed proposal in the oslo irc meeting was 1500 UTC with DST and 1600 UTC without DST, which translates to 3PM UTC and 4PM UTC accordingly. I other words, that means that we should move the slot from 1500 UTC to 1600 UTC with the recent time change. On Mon, Nov 16, 2020 at 2:51 PM Herve Beraud wrote: > Hello Oslofolk, > > As discussed during our previous meeting, at each DST change, the agenda > of some of us conflicting with our Oslo meeting time slot, this thread just > wants to propose a solution to avoid that. > > We could just move our meeting time when DST changes, and then move back > to this slot once DST is back. > > Right now our meeting time is UTC based, we suppose that UTC is required > because of the OpenStack meeting tooling. > > By following that we will get the following time slots: > > - meeting time slot when DST start: 5:00pm UTC > > - meeting time slot when DST end: 4:00pm UTC > > Does it fit well for you? > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > > -- Moisés Guimarães Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From zigo at debian.org Wed Nov 18 14:20:52 2020 From: zigo at debian.org (Thomas Goirand) Date: Wed, 18 Nov 2020 15:20:52 +0100 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: <5971221605688542@mail.yandex.ru> References: <4211161605171577@mail.yandex.ru> <5971221605688542@mail.yandex.ru> Message-ID: On 11/18/20 9:55 AM, Dmitriy Rabotyagov wrote: > Can you kindly share the way of doing that? As passing --config-file > with pyargv for uwsgi seems not the right way to do that. >   > 15.11.2020, 15:30, "Thomas Goirand" : > > I'll manage to get --config-file as parameters when starting daemons > (it's possible to do so, even when using uwsgi). > >   >   > --  > Kind Regards, > Dmitriy Rabotyagov >   As much as I know, the --pyargv *does* the right thing. Currently, in Debian, we have neutron-api started like this: /usr/bin/uwsgi_python37 \ --https-socket :9696,/etc/neutron/ssl/public/HOSTNAME.crt,/etc/neutron/ssl/private/HOSTNAME.pem \ --ini /etc/neutron/neutron-api-uwsgi.ini \ --pyargv "--config-dir=/etc/neutron/server.conf.d \ --config-file=/etc/neutron/neutron.conf \ --config-file=/etc/neutron/plugins/ml2/ml2_conf.ini" Though it's a little bit tricky. Notice the quotes so that there's only a single argument after --pyargv... All of this has been set in openstack-pkg-tools for a few years already, though it's only in use in Debian, because Ubuntu people don't use uwsgi (which isn't part of Ubuntu main, it's only in Universe). Cheers, Thomas Goirand (zigo) From ignaziocassano at gmail.com Wed Nov 18 14:21:21 2020 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Wed, 18 Nov 2020 15:21:21 +0100 Subject: [openstack][stein][cinder] iscsi multipath issues In-Reply-To: References: Message-ID: Hello I solved modifying the prio from alua to emc, and now multipath is cleaned when I migrate an instance. There is another issue: when I attach a new volume to the instance and then I detach the new volume, iscsi logout session also for the boot volume and the instance does non work anymore (it looses the boot volume). Regards Ignazio Il giorno mer 18 nov 2020 alle ore 12:26 Ignazio Cassano < ignaziocassano at gmail.com> ha scritto: > Hello Everyone, > I am testing stein with cinder iscsi driver for unity. > Since I became crazy on queens, I decided to try with stein. > At this time I have only one virtual machine with only one iscsi volume. > > It was running on podiscsivc-kvm02 and I migrated it on podiscsivc-kvm01. > > Let me show what multipath -ll displays on podiscsivc-kvm02 after live > migration: > > 36006016006e04400dce5b45f0ac77301 dm-3 DGC ,VRAID > size=40G features='1 retain_attached_hw_handler' hwhandler='1 alua' wp=rw > |-+- policy='round-robin 0' prio=0 status=active > | `- 17:0:0:60 sdm 8:192 failed faulty running > `-+- policy='round-robin 0' prio=0 status=enabled > |- 19:0:0:60 sdk 8:160 failed faulty running > `- 21:0:0:60 sdj 8:144 failed faulty running > > And now on destination node podiscsivc-kvm01: > 36006016006e04400dce5b45f0ac77301 dm-3 DGC ,VRAID > size=40G features='2 queue_if_no_path retain_attached_hw_handler' > hwhandler='1 alua' wp=rw > |-+- policy='round-robin 0' prio=50 status=active > | |- 17:0:0:14 sdm 8:192 active ready running > | `- 15:0:0:14 sdl 8:176 active ready running > `-+- policy='round-robin 0' prio=10 status=enabled > |- 21:0:0:14 sdj 8:144 active ready running > `- 19:0:0:14 sdk 8:160 active ready running > > On source node in /var/log/messages I get: > Nov 18 10:34:19 podiscsivc-kvm02 multipathd: > 36006016006e04400dce5b45f0ac77301: failed in domap for addition of new path > sdl > Nov 18 10:34:19 podiscsivc-kvm02 multipathd: > 36006016006e04400dce5b45f0ac77301: uev_add_path sleep > Nov 18 10:34:20 podiscsivc-kvm02 multipathd: > 36006016006e04400dce5b45f0ac77301: failed in domap for addition of new path > sdl > Nov 18 10:34:20 podiscsivc-kvm02 kernel: device-mapper: table: 253:3: > multipath: error getting device > Nov 18 10:34:20 podiscsivc-kvm02 kernel: device-mapper: ioctl: error > adding target to table > Nov 18 10:34:20 podiscsivc-kvm02 multipathd: > 36006016006e04400dce5b45f0ac77301: uev_add_path sleep > > On storage node seems it wotks fine, because the host access migrated from > source to destination node. > > Multipath.conf is the following: > > blacklist { > # Skip the files uner /dev that are definitely not FC/iSCSI devices > # Different system may need different customization > devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*" > devnode "^hd[a-z][0-9]*" > devnode "^cciss!c[0-9]d[0-9]*[p[0-9]*]" > > # Skip LUNZ device from VNX/Unity > device { > vendor "DGC" > product "LUNZ" > } > } > > defaults { > user_friendly_names no > flush_on_last_del yes > remove_retries 12 > skip_kpartx yes > } > > devices { > # Device attributed for EMC CLARiiON and VNX/Unity series ALUA > device { > vendor "DGC" > product ".*" > product_blacklist "LUNZ" > path_grouping_policy group_by_prio > path_selector "round-robin 0" > path_checker emc_clariion > features "0" > no_path_retry 12 > hardware_handler "1 alua" > prio alua > failback immediate > } > } > > Why it leaves failed faulty running devices ? > Is it a correct behaviour ? > Every time I migrate my single instance from a node to another the number > of files under /dev/disk/by-path increase of 4 (the number of path used for > unity storage) on the destination node. > > > I contacted Dell support and they said it is not an a problem of their > cinder driver but ti could be related to nova. > Please help me !!! > I must decide if acquire nfs storage or iscsi storage. > On the cinder compatibility drive matrix most vendors are iscsi. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From e0ne at e0ne.info Wed Nov 18 14:22:58 2020 From: e0ne at e0ne.info (Ivan Kolodyazhny) Date: Wed, 18 Nov 2020 16:22:58 +0200 Subject: [horizon] Weekly Meeting time poll Message-ID: Hi team, As discussed during the last meeting, let's vote for a new meeting time for Horizon. You can vote for the current time if it's OK for you: https://doodle.com/poll/a5eeh6h3v356w8ss Feel free to reach me by e-mail or in IRC if you have any questions. Regards, Ivan Kolodyazhny -------------- next part -------------- An HTML attachment was scrubbed... URL: From michapma at redhat.com Wed Nov 18 14:53:26 2020 From: michapma at redhat.com (Michael Chapman) Date: Thu, 19 Nov 2020 01:53:26 +1100 Subject: Where to send mascot graphic adjustment proposals In-Reply-To: References: Message-ID: James, Thanks for the help, I'll have a chat with the other Designate folks on IRC to see if there's much interest and we'll go from there. - Michael On Wed, Nov 18, 2020 at 4:30 AM James Cole wrote: > Hey Michael, > > I asked around and doesn’t look like we've previously been asked to edit a > mascot after it’s initial creation, so there’s no specific process in place > currently. You’re blazing a new trail here! > > We definitely want to gather consensus from project contributors before > making changes. The best way to do that would be the openstack-discuss > mailing list with [designate] in the subject line of any messages—as > documented here > . > Adding the tag should help other designate contributors notice and respond > with their input. > > If you can gather consensus there, you would then email > community at openinfra.dev regarding the change. > > So the process would be: propose change via mailing lists => gather > consensus => contact the foundation. > > And thanks again for flagging the broken email address and the alignment > issue on the page. > > Hope this helps! > > -James > > > On Nov 17, 2020, at 6:36 AM, Michael Chapman wrote: > > Hi James > > On Tue, Nov 17, 2020 at 4:26 AM James Cole wrote: > >> Hi Michael, >> >> I’m James Cole, a graphic designer at the Open Infrastructure Foundation. >> Hopefully I can address some of your questions. >> >> Regarding the diagram, I’m told it is managed by Designate in their >> documentation. We can provide suggestions but ultimately it is up to them >> how they want to create those docs. You may have to get in touch with an >> active contributor to that project. >> >> > I might not have explained this well, I am currently preparing an updated > version of the diagram and am a Designate contributor. > > >> Regarding mascot design changes, we’d need broader community input to >> make edits like that. The mascot designs undergo a community review >> process with each project when they’re created, so we’re unable to make >> design changes at this time. >> > > Can you be more specific on how the community can provide that input? Is > there a repo I can propose changes against? > > >> If it helps, the mark is vertically aligned with the text, not base >> aligned. Enlarging the crocodile will probably make it seem >> disproportionately large compared with other project mascots, which all >> follow the same design rules. >> > > I think what I'm saying is I don't think vertical alignment makes sense > with such a strong horizontal line at the base of the logo. Maybe in the > context of a group of mascots + text having all of them vertically aligned > looks less strange but on its own I think it would look better aligned to > the base. > > Ultimately if it's not possible to change this I can always use the > vertical logo + text instead, but I thought I'd see if it could be improved > first. > > >> Thanks for flagging the inactive email address for Anne. Would you mind >> providing the URL of the page you found that address? We will replace it >> with community at openinfra.dev as the contact email for mascots. >> >> https://www.openstack.org/project-mascots/ right down the bottom > > On a related note I had a look at > https://www.openstack.org/software/project-navigator/openstack-components#openstack-services > and the designate entry there doesn't seem to be centered vertically and > might need some attention as well. > > Thanks for reaching out! >> > > > Thanks for the detailed response! > > - Michael > > >> >> *James Cole* >> Graphic Designer >> Open Infrastructure Foundation >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noonedeadpunk at ya.ru Wed Nov 18 15:06:32 2020 From: noonedeadpunk at ya.ru (Dmitriy Rabotyagov) Date: Wed, 18 Nov 2020 17:06:32 +0200 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: <4211161605171577@mail.yandex.ru> <5971221605688542@mail.yandex.ru> Message-ID: <661281605711741@mail.yandex.ru> An HTML attachment was scrubbed... URL: From mark at stackhpc.com Wed Nov 18 15:06:53 2020 From: mark at stackhpc.com (Mark Goddard) Date: Wed, 18 Nov 2020 15:06:53 +0000 Subject: [kolla][ptg] Kolla Wallaby priorities In-Reply-To: References: Message-ID: On Fri, 30 Oct 2020 at 20:26, Mark Goddard wrote: > > Hi, > > Thanks to everyone who attended the Kolla PTG sessions, we covered a > lot of ground. The Etherpad is available at [1]. I wrote an email [2] > summarising the discussions. I have moved candidate work items across > to a second Etherpad [2] for voting on. > > Now is the time to vote! Please add your name against a maximum of 12 > items across the 3 deliverables (kolla, kolla-ansible, kayobe) in the > priorities [2] Etherpad. Anyone in the community is welcome to vote. > > [1] https://etherpad.opendev.org/p/kolla-wallaby-ptg > [2] http://lists.openstack.org/pipermail/openstack-discuss/2020-October/018445.html > [3] https://etherpad.opendev.org/p/kolla-wallaby-priorities I'll close the poll at the end of this week. Please get your votes in before then. > > Thanks, > Mark From marios at redhat.com Wed Nov 18 15:23:31 2020 From: marios at redhat.com (Marios Andreou) Date: Wed, 18 Nov 2020 17:23:31 +0200 Subject: [tripleo] next meeting Tuesday Nov 24 @ 1400 UTC in #tripleo Message-ID: Hello TripleOs reminder our next scheduled irc meeting is ** Tuesday 24th November at 1400 UTC in #tripleo. ** ** https://etherpad.opendev.org/p/tripleo-meeting-items ** Please add anything you want to raise at https://etherpad.opendev.org/p/tripleo-meeting-items This could be anything including review requests, any blocking issues or major ongoing work. Our last meeting was held on the 10th - you can find the logs there http://eavesdrop.openstack.org/meetings/tripleo/2020/tripleo.2020-11-10-14.00.log.html thanks, marios -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry at openstack.org Wed Nov 18 15:53:10 2020 From: thierry at openstack.org (Thierry Carrez) Date: Wed, 18 Nov 2020 16:53:10 +0100 Subject: [largescale-sig] Next meeting: November 18, 14utc In-Reply-To: References: Message-ID: <6af54866-b87b-7cc6-b4f1-0ab6796959e3@openstack.org> We held our meeting today and discussed how well our Forum and PTG sessions went, as well as the plan and things we should change for Wallaby. Our new chairs will be Belmiro Moreira, Gene Kuo and myself. Meeting logs at: http://eavesdrop.openstack.org/meetings/large_scale_sig/2020/large_scale_sig.2020-11-18-14.01.html TODOs: - ttx to refactor wiki and other etherpads into that "journey" FAQ view - genekuo to review/approve https://review.opendev.org/#/c/755069/ - ttx to set up release jobs and request a 0.1 release - ttx to reschedule meeting to be biweekly on Wednesdays, 15utc - all to think about how to improve how we collect feedback Our next meeting will be Wednesday, December 2 at 15utc in #openstack-meeting-3 on Freenode IRC. -- Thierry Carrez (ttx) From johnsomor at gmail.com Wed Nov 18 16:46:45 2020 From: johnsomor at gmail.com (Michael Johnson) Date: Wed, 18 Nov 2020 08:46:45 -0800 Subject: [octavia] Octavia weekly IRC meeting is cancelled November 25th Message-ID: A number of the Octavia community members will be taking vacation next week, so we will be cancelling the meeting next week on the 25th. Enjoy your break! Michael From ignaziocassano at gmail.com Wed Nov 18 16:56:08 2020 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Wed, 18 Nov 2020 17:56:08 +0100 Subject: [openstack][stein][cinder] iscsi multipath issues In-Reply-To: References: Message-ID: Hello, further news.The problem is not the multipath.conf.......sorry for the mistake.The problem is the first connection from each iscsi initiator (compute node).Seems we must start from a clean configuration where the first 4 paths created at the first login refer to the same disk names an all nodes.If a node have a dirty configuration and have sdb allocated by an iscsi path for old misconfiguration, it alloccates sdc,sdd,sde,sdf. Another node wich start with a clean configuration, allocates sdb,sdc,sdd,sde.So, on the first node, the first instance allocates sgh,sdd and so on.But If I migrate the instance to the another node, some faulty device appears.If at the first iscsi login all node all cleaned, all seems to work fine. Ignazio Il giorno mer 18 nov 2020 alle ore 15:21 Ignazio Cassano < ignaziocassano at gmail.com> ha scritto: > Hello I solved modifying the prio from alua to emc, and now multipath is > cleaned when I migrate an instance. > There is another issue: > when I attach a new volume to the instance and then I detach the new > volume, iscsi logout session also for the boot volume and the instance > does non work anymore (it looses the boot volume). > Regards > Ignazio > > Il giorno mer 18 nov 2020 alle ore 12:26 Ignazio Cassano < > ignaziocassano at gmail.com> ha scritto: > >> Hello Everyone, >> I am testing stein with cinder iscsi driver for unity. >> Since I became crazy on queens, I decided to try with stein. >> At this time I have only one virtual machine with only one iscsi volume. >> >> It was running on podiscsivc-kvm02 and I migrated it on podiscsivc-kvm01. >> >> Let me show what multipath -ll displays on podiscsivc-kvm02 after live >> migration: >> >> 36006016006e04400dce5b45f0ac77301 dm-3 DGC ,VRAID >> size=40G features='1 retain_attached_hw_handler' hwhandler='1 alua' wp=rw >> |-+- policy='round-robin 0' prio=0 status=active >> | `- 17:0:0:60 sdm 8:192 failed faulty running >> `-+- policy='round-robin 0' prio=0 status=enabled >> |- 19:0:0:60 sdk 8:160 failed faulty running >> `- 21:0:0:60 sdj 8:144 failed faulty running >> >> And now on destination node podiscsivc-kvm01: >> 36006016006e04400dce5b45f0ac77301 dm-3 DGC ,VRAID >> size=40G features='2 queue_if_no_path retain_attached_hw_handler' >> hwhandler='1 alua' wp=rw >> |-+- policy='round-robin 0' prio=50 status=active >> | |- 17:0:0:14 sdm 8:192 active ready running >> | `- 15:0:0:14 sdl 8:176 active ready running >> `-+- policy='round-robin 0' prio=10 status=enabled >> |- 21:0:0:14 sdj 8:144 active ready running >> `- 19:0:0:14 sdk 8:160 active ready running >> >> On source node in /var/log/messages I get: >> Nov 18 10:34:19 podiscsivc-kvm02 multipathd: >> 36006016006e04400dce5b45f0ac77301: failed in domap for addition of new path >> sdl >> Nov 18 10:34:19 podiscsivc-kvm02 multipathd: >> 36006016006e04400dce5b45f0ac77301: uev_add_path sleep >> Nov 18 10:34:20 podiscsivc-kvm02 multipathd: >> 36006016006e04400dce5b45f0ac77301: failed in domap for addition of new path >> sdl >> Nov 18 10:34:20 podiscsivc-kvm02 kernel: device-mapper: table: 253:3: >> multipath: error getting device >> Nov 18 10:34:20 podiscsivc-kvm02 kernel: device-mapper: ioctl: error >> adding target to table >> Nov 18 10:34:20 podiscsivc-kvm02 multipathd: >> 36006016006e04400dce5b45f0ac77301: uev_add_path sleep >> >> On storage node seems it wotks fine, because the host access migrated >> from source to destination node. >> >> Multipath.conf is the following: >> >> blacklist { >> # Skip the files uner /dev that are definitely not FC/iSCSI devices >> # Different system may need different customization >> devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*" >> devnode "^hd[a-z][0-9]*" >> devnode "^cciss!c[0-9]d[0-9]*[p[0-9]*]" >> >> # Skip LUNZ device from VNX/Unity >> device { >> vendor "DGC" >> product "LUNZ" >> } >> } >> >> defaults { >> user_friendly_names no >> flush_on_last_del yes >> remove_retries 12 >> skip_kpartx yes >> } >> >> devices { >> # Device attributed for EMC CLARiiON and VNX/Unity series ALUA >> device { >> vendor "DGC" >> product ".*" >> product_blacklist "LUNZ" >> path_grouping_policy group_by_prio >> path_selector "round-robin 0" >> path_checker emc_clariion >> features "0" >> no_path_retry 12 >> hardware_handler "1 alua" >> prio alua >> failback immediate >> } >> } >> >> Why it leaves failed faulty running devices ? >> Is it a correct behaviour ? >> Every time I migrate my single instance from a node to another the number >> of files under /dev/disk/by-path increase of 4 (the number of path used for >> unity storage) on the destination node. >> >> >> I contacted Dell support and they said it is not an a problem of their >> cinder driver but ti could be related to nova. >> Please help me !!! >> I must decide if acquire nfs storage or iscsi storage. >> On the cinder compatibility drive matrix most vendors are iscsi. >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ninorhce at gmail.com Tue Nov 17 17:34:04 2020 From: ninorhce at gmail.com (ninad jadhav) Date: Tue, 17 Nov 2020 09:34:04 -0800 Subject: Failed to Create Virtual Instances for manila Service Due to neutron and nova Services In-Reply-To: References: Message-ID: Sure, here it is. https://gist.github.com/Ninad-cloud/361cb5aacd4810c2fb5b4840d5af96d6 I don't understand why it is not allowing to SSH to 10.254.0.0/16. regards, Ninad -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.m.budnik at gmail.com Wed Nov 18 16:29:57 2020 From: r.m.budnik at gmail.com (Roman Budnyk) Date: Wed, 18 Nov 2020 18:29:57 +0200 Subject: Fwd: [sdk] issue in update image method In-Reply-To: References: Message-ID: Hello dear developers, I was trying to update image data by calling method *update_image_properties. *Each time I was facing the error: TypeError: existing() argument after ** must be a mapping, not str I did small research in the source code and found a strange solution. Could you please check this place in the code: class BaseImageProxy, method update_image_properties (path /openstack/_base_proxy.py): [image: image.png] When I changed it to the below - everything works (with name, id or image instance): [image: image.png] could you please check on your end, why the construction *if image is None *is using and how can we execute the code *self._connection.get_image(image) *if None is passing as the argument. Many thanks! Regards, Roman -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 25115 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 23505 bytes Desc: not available URL: From stefan.bujack at desy.de Wed Nov 18 18:46:10 2020 From: stefan.bujack at desy.de (Bujack, Stefan) Date: Wed, 18 Nov 2020 19:46:10 +0100 (CET) Subject: [horizon] Error when clicking instance detailed view after upgrading from ussuri to victoria Message-ID: <1024527276.24734200.1605725170754.JavaMail.zimbra@desy.de> Hello, I am a little lost here. Hopefully some of you nice people could help me with this issue please. We had an Openstack Ussuri deployment on Ubuntu 20.04 and upgraded to Victoria Release via cloud_archive repository Now when I click on any instance for a detailed view I get an error 500 with the following message: ==> /var/log/apache2/error.log <== [Wed Nov 18 19:42:37.883040 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] /usr/lib/python3/dist-packages/django/contrib/staticfiles/templatetags/staticfiles.py:24: RemovedInDjango30Warning: {% load staticfiles %} is deprecated in favor of {% load static %}. [Wed Nov 18 19:42:37.883091 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] warnings.warn( [Wed Nov 18 19:42:37.886358 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] ERROR django.request Internal Server Error: /project/instances/25d58259-9d9d-4215-8fb6-521ff9a5befe/ [Wed Nov 18 19:42:37.886400 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] Traceback (most recent call last): [Wed Nov 18 19:42:37.886407 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 829, in _resolve_lookup [Wed Nov 18 19:42:37.886412 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] current = current[bit] [Wed Nov 18 19:42:37.886416 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] TypeError: 'Server' object is not subscriptable [Wed Nov 18 19:42:37.886421 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] [Wed Nov 18 19:42:37.886425 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] During handling of the above exception, another exception occurred: [Wed Nov 18 19:42:37.886430 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] [Wed Nov 18 19:42:37.886456 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] Traceback (most recent call last): [Wed Nov 18 19:42:37.886460 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/openstack_dashboard/api/base.py", line 139, in __getattribute__ [Wed Nov 18 19:42:37.886465 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return object.__getattribute__(self, attr) [Wed Nov 18 19:42:37.886469 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] AttributeError: 'Server' object has no attribute 'OS-EXT-SRV-ATTR:instance_name' [Wed Nov 18 19:42:37.886473 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] [Wed Nov 18 19:42:37.886477 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] During handling of the above exception, another exception occurred: [Wed Nov 18 19:42:37.886482 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] [Wed Nov 18 19:42:37.886486 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] Traceback (most recent call last): [Wed Nov 18 19:42:37.886501 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line 34, in inner [Wed Nov 18 19:42:37.886647 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] response = get_response(request) [Wed Nov 18 19:42:37.886651 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 145, in _get_response [Wed Nov 18 19:42:37.886656 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] response = self.process_exception_by_middleware(e, request) [Wed Nov 18 19:42:37.886661 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 143, in _get_response [Wed Nov 18 19:42:37.886665 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] response = response.render() [Wed Nov 18 19:42:37.886668 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/response.py", line 106, in render [Wed Nov 18 19:42:37.886672 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] self.content = self.rendered_content [Wed Nov 18 19:42:37.886676 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/response.py", line 83, in rendered_content [Wed Nov 18 19:42:37.886680 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] content = template.render(context, self._request) [Wed Nov 18 19:42:37.886684 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/backends/django.py", line 61, in render [Wed Nov 18 19:42:37.886688 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.template.render(context) [Wed Nov 18 19:42:37.886692 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 171, in render [Wed Nov 18 19:42:37.886696 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self._render(context) [Wed Nov 18 19:42:37.886700 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 163, in _render [Wed Nov 18 19:42:37.886704 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.nodelist.render(context) [Wed Nov 18 19:42:37.886708 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.886717 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.886721 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.886725 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.886730 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/loader_tags.py", line 150, in render [Wed Nov 18 19:42:37.886863 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return compiled_parent._render(context) [Wed Nov 18 19:42:37.886871 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 163, in _render [Wed Nov 18 19:42:37.886875 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.nodelist.render(context) [Wed Nov 18 19:42:37.886894 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.886898 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.886902 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.886906 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.886909 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/loader_tags.py", line 62, in render [Wed Nov 18 19:42:37.886913 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] result = block.nodelist.render(context) [Wed Nov 18 19:42:37.886917 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.886945 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.886973 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.886978 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.886982 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/loader_tags.py", line 62, in render [Wed Nov 18 19:42:37.886986 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] result = block.nodelist.render(context) [Wed Nov 18 19:42:37.886991 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.886996 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.887001 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.887006 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.887019 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 987, in render [Wed Nov 18 19:42:37.887093 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] output = self.filter_expression.resolve(context) [Wed Nov 18 19:42:37.887101 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 671, in resolve [Wed Nov 18 19:42:37.887105 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] obj = self.var.resolve(context) [Wed Nov 18 19:42:37.887109 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 796, in resolve [Wed Nov 18 19:42:37.887113 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] value = self._resolve_lookup(context) [Wed Nov 18 19:42:37.887117 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 858, in _resolve_lookup [Wed Nov 18 19:42:37.887121 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] current = current() [Wed Nov 18 19:42:37.887155 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/horizon/tabs/base.py", line 227, in render [Wed Nov 18 19:42:37.887221 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return render_to_string(self.template_name, {"tab_group": self}) [Wed Nov 18 19:42:37.887236 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/loader.py", line 62, in render_to_string [Wed Nov 18 19:42:37.887242 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return template.render(context, request) [Wed Nov 18 19:42:37.887246 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/backends/django.py", line 61, in render [Wed Nov 18 19:42:37.887250 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.template.render(context) [Wed Nov 18 19:42:37.887254 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 171, in render [Wed Nov 18 19:42:37.887258 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self._render(context) [Wed Nov 18 19:42:37.887262 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 163, in _render [Wed Nov 18 19:42:37.887267 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.nodelist.render(context) [Wed Nov 18 19:42:37.887272 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.887276 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.887280 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.887284 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.887288 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/loader_tags.py", line 150, in render [Wed Nov 18 19:42:37.887293 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return compiled_parent._render(context) [Wed Nov 18 19:42:37.887297 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 163, in _render [Wed Nov 18 19:42:37.887382 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.nodelist.render(context) [Wed Nov 18 19:42:37.887395 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.887403 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.887407 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.887411 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.887415 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/defaulttags.py", line 513, in render [Wed Nov 18 19:42:37.887425 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.nodelist.render(context) [Wed Nov 18 19:42:37.887429 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.887434 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.887438 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.887443 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.887448 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/defaulttags.py", line 309, in render [Wed Nov 18 19:42:37.887453 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return nodelist.render(context) [Wed Nov 18 19:42:37.887458 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.887462 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.887467 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.887472 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.887478 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/defaulttags.py", line 209, in render [Wed Nov 18 19:42:37.887483 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] nodelist.append(node.render_annotated(context)) [Wed Nov 18 19:42:37.887488 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.887493 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.887498 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 987, in render [Wed Nov 18 19:42:37.887503 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] output = self.filter_expression.resolve(context) [Wed Nov 18 19:42:37.887587 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 671, in resolve [Wed Nov 18 19:42:37.887594 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] obj = self.var.resolve(context) [Wed Nov 18 19:42:37.887598 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 796, in resolve [Wed Nov 18 19:42:37.887602 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] value = self._resolve_lookup(context) [Wed Nov 18 19:42:37.887606 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 858, in _resolve_lookup [Wed Nov 18 19:42:37.887610 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] current = current() [Wed Nov 18 19:42:37.887614 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/horizon/tabs/base.py", line 372, in render [Wed Nov 18 19:42:37.887619 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return render_to_string(self.get_template_name(self.request), context) [Wed Nov 18 19:42:37.887634 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/loader.py", line 62, in render_to_string [Wed Nov 18 19:42:37.887638 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return template.render(context, request) [Wed Nov 18 19:42:37.887642 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/backends/django.py", line 61, in render [Wed Nov 18 19:42:37.887652 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.template.render(context) [Wed Nov 18 19:42:37.887657 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 171, in render [Wed Nov 18 19:42:37.887661 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self._render(context) [Wed Nov 18 19:42:37.887665 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 163, in _render [Wed Nov 18 19:42:37.887669 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.nodelist.render(context) [Wed Nov 18 19:42:37.887673 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.887678 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.887682 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.887686 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.887691 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/defaulttags.py", line 302, in render [Wed Nov 18 19:42:37.887696 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] match = condition.eval(context) [Wed Nov 18 19:42:37.887707 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/defaulttags.py", line 876, in eval [Wed Nov 18 19:42:37.887711 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.value.resolve(context, ignore_failures=True) [Wed Nov 18 19:42:37.887729 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 671, in resolve [Wed Nov 18 19:42:37.887734 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] obj = self.var.resolve(context) [Wed Nov 18 19:42:37.887739 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 796, in resolve [Wed Nov 18 19:42:37.887744 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] value = self._resolve_lookup(context) [Wed Nov 18 19:42:37.887748 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 837, in _resolve_lookup [Wed Nov 18 19:42:37.887753 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] current = getattr(current, bit) [Wed Nov 18 19:42:37.887758 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/openstack_dashboard/api/base.py", line 139, in __getattribute__ [Wed Nov 18 19:42:37.887763 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return object.__getattribute__(self, attr) [Wed Nov 18 19:42:37.887767 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/openstack_dashboard/api/_nova.py", line 88, in has_extended_attrs [Wed Nov 18 19:42:37.887772 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return any(getattr(self, attr) for attr in [ [Wed Nov 18 19:42:37.887777 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/openstack_dashboard/api/_nova.py", line 88, in [Wed Nov 18 19:42:37.887782 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return any(getattr(self, attr) for attr in [ [Wed Nov 18 19:42:37.887786 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/openstack_dashboard/api/base.py", line 144, in __getattribute__ [Wed Nov 18 19:42:37.887791 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return getattr(self._apiresource, attr) [Wed Nov 18 19:42:37.887795 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/novaclient/base.py", line 176, in __getattr__ [Wed Nov 18 19:42:37.887800 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] raise AttributeError(k) [Wed Nov 18 19:42:37.887805 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] AttributeError: OS-EXT-SRV-ATTR:instance_name Thanks in advance, Stefan Bujack From jp.methot at planethoster.info Wed Nov 18 19:03:47 2020 From: jp.methot at planethoster.info (=?utf-8?Q?Jean-Philippe_M=C3=A9thot?=) Date: Wed, 18 Nov 2020 14:03:47 -0500 Subject: [neutron] HA network issues on Rocky Message-ID: Hi, We’ve been running an Openstack setup in production for several years and we upgraded it to Rocky last May. We are now creating a router for a new project for the first time since that upgrade and we’ve been running into issues with L3HA for that router. Essentially, the router for this project gets initialized with a faulty HA network. How do I know it’s faulty? -Both Keepalived instances think they are master. -Both HA network ports get the wrong MTU (9000 instead of 8958) -Even if I manually set the proper MTU, VRRP packets don’t get received on the other node -If I then disable and enable the router, MTU gets rolled back to 9000 -If I force the MTU for this port through the neutron database, it will also get rolled back to 9000 once the router gets recreated This setup is using openvswitch and GRE tunnels. I have 7 other projects with L3HA routers running and they do not have this issue, even if I create new routers in them. They are also older projects created before the upgrade to Rocky. This problem is strictly isolated to this new project. I’m not sure exactly what’s going on here and why Openstack isn’t taking encapsulation into account when automatically setting its HA network MTU for this. Any suggestion on how to figure out what’s happening behind the scene? Jean-Philippe Méthot Senior Openstack system administrator Administrateur système Openstack sénior PlanetHoster inc. 4414-4416 Louis B Mayer Laval, QC, H7P 0G1, Canada TEL : +1.514.802.1644 - Poste : 2644 FAX : +1.514.612.0678 CA/US : 1.855.774.4678 FR : 01 76 60 41 43 UK : 0808 189 0423 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dms at danplanet.com Wed Nov 18 19:24:00 2020 From: dms at danplanet.com (Dan Smith) Date: Wed, 18 Nov 2020 11:24:00 -0800 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: Message-ID: > There was a long discussion on #openstack-nova today[3] around this > topic. So you can find more detailed reasoning there[3]. I just had a long voice chat with Ollie about this, trying to understand some of the challenges that still exist with some of the things we've discussed and the proposed forward steps. There are lots of things to clarify, I think, and we could honestly probably use a wider voice chat among the people that need to work on this. However, I'll try here. First off, I want to address the "do it like devstack" recommendation, and the subsequent suggestion of standardizing on something like a "nova-db.conf" file arrangement to keep the db credentials in one place. As Ollie has pointed out, devstack doesn't support all the various deployment arrangements (such as "one metadata api per cell") and thus doesn't have a prescription for how to arrange the config files in those scenarios. Specifically, an all-in-one deployment that includes multiple API services with different configs would currently have to hack around the hardcoded nova.conf file with the environment variable that allows them to specify a directory other than /etc/nova.conf. Devstack doesn't have to do this because it doesn't support that arrangement of services, but if it did, it would have to. So, I wanted to clarify something that came out of the IRC discussion, which is "do it like devstack". When we say that, or at least when *I* said it, we meant "have different config files for each service so that you can get the config elements appropriate for each service set correctly." That doesn't mean "nova-compute should point to /etc/nova/nova-cpu.conf because that's what devstack does". Especially in a containerized setup, I would expect everything to use /etc/nova/nova.conf, since those are namespaced per-service because of the containerization. Further, just because devstack doesn't run a metadata per cell (or any other such optional arrangement), obviously that doesn't mean you can't. That leads me to the first action item I think we need: ACTION 1: Make the wsgi app able to use something other than nova.conf All of our other services support a --config-file flag, and I don't see why we wouldn't allow this if it's necessary for deployments. In the pure API arrangement, it shouldn't really be necessary to change this, but clearly you may need to have multiple API workers with different configs, as is the case with metadata-per-cell, or even potentially some admin-focused private API endpoint. If it makes it easier for deployment tools to start the API workers with a specific config file, we should let them do that. You can already work around that hard-coded filename by setting OS_NOVA_CONFIG_DIR to something other than /etc/nova, but we shouldn't require them to create directories just to have separate configs. The next item is related: ACTION 2: We need to document a minimal viable config for each service Ollie points out that, obviously, handing the deployer a config reference with 1.21 bajillion config options does not clearly indicate which services need which thing, and especially, which things are _not_allowed_ to be set for a service (such as db credentials on the compute). We can't feasibly audit every config option we have, but it would be very helpful to have a reference that shows what a completely minimal configuration for each service looks like. We could do that by tagging services per config options (which I suggested earlier, and would still be good) but I think maybe a standalone document would be easier for people to follow. Now, on to the question about the hard-fail patch for compute: https://review.opendev.org/#/c/762176/ The Nova devs have wanted people to _not_ have db credentials in the config file that nova-compute can see for a "Very Long Time." We have even made some assumptions in the code that rely on these credentials being not set on the compute, which is at least partially why we're having this conversation (again) now. Despite the fact that nobody *should* be setting these credentials in their config file, we know that at in least some circumstances, they are. TripleO is setting them (always I think?) because puppet-nova does that. OSA has said that they're setting them somewhat incidentally when they do all-in-one deployments. The latter is unlikely to affect any real deployments, but the former definitely _will_, and anyone else that isn't present in this discussion may be including credentials unnecessarily, which we will break when we merge that patch. Thus, I think that, even though it feels long overdue for devs, the most prudent and cautious approach will be to: ACTION 3: Not merge that hard fail until X We have the warning, we have the reno. We expect that the deployment tools will be working to eliminate the credentials for the compute config, but merging that will make it an emergency for them. We've waited years at this point, we can wait one more cycle for safety. As Ollie pointed out, we've not been super clear about messaging this, despite it being a well-worn assumption amongst the developers for a long time. To aid in smoking out any of the jobs or configs that deployment tools may still have which will break when we merge that patch, we should also consider: ACTION 4: A workaround flag to opt-in to the strict checking Basically, this would be a one or two-cycle workaround, which when enabled, would opt-in to the (above) behavior of causing compute to fail on startup if db credentials are present. This would allow the deployment tool maintainers, as well as people responsible for CI jobs to smoke test the new behavior early, before we merge it and cause an emergency for them. We can set this as on by default in our devstack jobs to signal that it is good with the new behavior, and also encourage the other deployment projects to set it as well once they're generating clean configs for their nova-computes. Once we merge the patch to actually fail all the time, we can remove this workaround config, according to the original intent of the workarounds group, that those flags are short-lived. We could do this by altering gibi's patch to only fail if the workaround is enabled, and then follow up in X by removing the workaround check. So, I know that was a lot of words, but I think if we can agree to the above four items, we'll have a path forward that doesn't overly burden any one specific group while still allowing us to chart a path to getting where we want to be. I think we need acks from a bunch of groups, probably at least: - Nova (gibi, stephenfin) - TripleO (owalsh) - Debian (zigo) - Kolla (yoctozepto) - OSA (noonedeadpunk) - rdo-ci (jpena) - puppet-nova (tkajinam) Are people okay with these action items? --Dan From rosmaita.fossdev at gmail.com Wed Nov 18 20:03:44 2020 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Wed, 18 Nov 2020 15:03:44 -0500 Subject: [cinder] python-cinderclient: API v2 support removed in Wallaby In-Reply-To: <73f3c4b6-4040-d2a0-ff78-228645b586af@gmail.com> References: <73f3c4b6-4040-d2a0-ff78-228645b586af@gmail.com> Message-ID: <66181933-69d6-a79f-c6bb-ba0c8e785b60@gmail.com> Having heard no adverse comments about this proposal, the Cinder team plans to remove Block Storage API v2 support from the python-cinderclient during the current development cycle. cheers, brian On 11/12/20 9:57 AM, Brian Rosmaita wrote: > As announced previously on this mailing list [0], at yesterday's Cinder > meeting the Cinder team discussed the timeline for removing Block > Storage API v2 support from the python-cinderclient.  The Block Storage > API v2, which has been deprecated since Pike, will not be present in the > OpenStack Wallaby release. > > The team decided not to delay removing Block Storage API v2 support from > the python-cinderclient.  Thus, v2 support will *not* be available in > the Wallaby python-cinderclient. > > Given the long deprecation period, we trust that this will not adversely > impact too many users.  We point out that microversion 3.0 of the Block > Storage API v3 is functionally identical to v2; thus scripts that rely > on v2 responses should continue to work with minimal changes.  We also > point out that v3 has been available since Mitaka and has reached > microversion 3.62 with the Victoria release; thus it may be worth > re-examining such scripts to see what functionality you are missing out on. > > This email serves both as an announcement and a final call for comments > about this proposal.  Please reply to this email thread with any > comments before next week's Cinder meeting (Wednesday 18 November 2020). > > Thank you, > brian > > > [0] > http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018531.html > From artem.goncharov at gmail.com Wed Nov 18 19:06:21 2020 From: artem.goncharov at gmail.com (Artem Goncharov) Date: Wed, 18 Nov 2020 20:06:21 +0100 Subject: [sdk] issue in update image method In-Reply-To: References: Message-ID: Hi Roman, Can you please include some code you use to invoke the mentioned function? I assume you might be calling it in the context that we were not expecting. Thanks, Artem ---- typed from mobile, auto-correct typos assumed ---- On Wed, 18 Nov 2020, 19:55 Roman Budnyk, wrote: > Hello dear developers, > > I was trying to update image data by calling method *update_image_properties. > *Each time I was facing the error: TypeError: existing() argument after > ** must be a mapping, not str > > I did small research in the source code and found a strange solution. > Could you please check this place in the code: > class BaseImageProxy, method update_image_properties (path > /openstack/_base_proxy.py): > > [image: image.png] > When I changed it to the below - everything works (with name, id or image > instance): > [image: image.png] > could you please check on your end, why the construction *if image is > None *is using and how can we execute the code *self._connection.get_image(image) > *if None is passing as the argument. > > Many thanks! > Regards, > Roman > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 25115 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 23505 bytes Desc: not available URL: From r.m.budnik at gmail.com Wed Nov 18 20:08:19 2020 From: r.m.budnik at gmail.com (Roman Budnyk) Date: Wed, 18 Nov 2020 22:08:19 +0200 Subject: [sdk] issue in update image method In-Reply-To: References: Message-ID: Hello Artem, Thanks for the reply. Actually, I am doing nothing special. Calling the method from the client instance and passing there image name (or id): [image: image.png] after analyzing sdk code I came to the understanding that the update_image_properties method should work as with string representation of name (id) of the image or with the instance of the image class (not sure of it's name, but it does not matter here, can be received from the get_image() method. Please let me know if I can give you any additional information on this. Appreciate your help. ср, 18 лист. 2020 о 21:06 Artem Goncharov пише: > Hi Roman, > > Can you please include some code you use to invoke the mentioned function? > > I assume you might be calling it in the context that we were not expecting. > > Thanks, > Artem > > ---- > typed from mobile, auto-correct typos assumed > ---- > > On Wed, 18 Nov 2020, 19:55 Roman Budnyk, wrote: > >> Hello dear developers, >> >> I was trying to update image data by calling method *update_image_properties. >> *Each time I was facing the error: TypeError: existing() argument after >> ** must be a mapping, not str >> >> I did small research in the source code and found a strange solution. >> Could you please check this place in the code: >> class BaseImageProxy, method update_image_properties (path >> /openstack/_base_proxy.py): >> >> [image: image.png] >> When I changed it to the below - everything works (with name, id or image >> instance): >> [image: image.png] >> could you please check on your end, why the construction *if image is >> None *is using and how can we execute the code *self._connection.get_image(image) >> *if None is passing as the argument. >> >> Many thanks! >> Regards, >> Roman >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 25115 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 23505 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 20322 bytes Desc: not available URL: From artem.goncharov at gmail.com Wed Nov 18 20:25:43 2020 From: artem.goncharov at gmail.com (Artem Goncharov) Date: Wed, 18 Nov 2020 21:25:43 +0100 Subject: [sdk] issue in update image method In-Reply-To: References: Message-ID: You are absolutely right, it's all matter of what you pass as an image. I guess you have a problem due to mixing of different sdk layers of objects (use connection.get_image and pass it in connection.image.xxx). This is not designed to work this way and may really show weird behavior. You are advised to use directly conn.image.xxx methods. The so called cloud layer (conn.get_xxx or self._connection) is designed to be a level above the "proxy" and designed to give a higher level access. Those are generally either to wrap multiple different operations in a single function or normalize cloud differences. And it might return not completely compatible objects (both are interpretation of the image, but not exchangeable). If you want to use it this way you should pass image.id (image['id']) into other functions. I know this is a bit weird, but there are reasons for that. Artem On Wed, 18 Nov 2020, 21:08 Roman Budnyk, wrote: > Hello Artem, > > Thanks for the reply. > Actually, I am doing nothing special. Calling the method from the client > instance and passing there image name (or id): > > after analyzing sdk code I came to the understanding that the > update_image_properties method should work as with string representation of > name (id) of the image or with the instance of the image class (not sure of > it's name, but it does not matter here, can be received from > the get_image() method. > > Please let me know if I can give you any additional information on this. > Appreciate your help. > > ср, 18 лист. 2020 о 21:06 Artem Goncharov > пише: > >> Hi Roman, >> >> Can you please include some code you use to invoke the mentioned function? >> >> I assume you might be calling it in the context that we were not >> expecting. >> >> Thanks, >> Artem >> >> ---- >> typed from mobile, auto-correct typos assumed >> ---- >> >> On Wed, 18 Nov 2020, 19:55 Roman Budnyk, wrote: >> >>> Hello dear developers, >>> >>> I was trying to update image data by calling method *update_image_properties. >>> *Each time I was facing the error: TypeError: existing() argument after >>> ** must be a mapping, not str >>> >>> I did small research in the source code and found a strange solution. >>> Could you please check this place in the code: >>> class BaseImageProxy, method update_image_properties (path >>> /openstack/_base_proxy.py): >>> >>> >>> When I changed it to the below - everything works (with name, id or >>> image instance): >>> >>> could you please check on your end, why the construction *if image is >>> None *is using and how can we execute the code *self._connection.get_image(image) >>> *if None is passing as the argument. >>> >>> Many thanks! >>> Regards, >>> Roman >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From victoria at vmartinezdelacruz.com Wed Nov 18 21:52:44 2020 From: victoria at vmartinezdelacruz.com (=?UTF-8?Q?Victoria_Mart=C3=ADnez_de_la_Cruz?=) Date: Wed, 18 Nov 2020 18:52:44 -0300 Subject: [manila] Proposing Maari Tamm for python-manilaclient core Message-ID: Hi everyone, It's a great pleasure for me to propose Maari Tamm (maaritamm) for the python-manilaclient core group. Maari joined us as an Outreachy intern working on the manila support for openstackclient in December 2019. She excelled at delivering the main task, and she went above and beyond by continuing to contribute with the community even after her internship finished. She now continues submitting enhancements for the different manila components and taking on new challenges as they appear. Not only that, Maari joined us as mentor for the manila project in different efforts we have made: the Open Source Day in Grace Hopper Celebration 2020 and also mentoring for three students from the Boston University that are currently working with us in manila. Maari is a truly valuable member of our team and I believe she will be a great addition to the python-manilaclient core reviewers group. Looking forward to a positive response. All the best, Victoria -------------- next part -------------- An HTML attachment was scrubbed... URL: From jp.methot at planethoster.info Wed Nov 18 22:27:14 2020 From: jp.methot at planethoster.info (=?utf-8?Q?Jean-Philippe_M=C3=A9thot?=) Date: Wed, 18 Nov 2020 17:27:14 -0500 Subject: [neutron] HA network issues on Rocky In-Reply-To: References: Message-ID: We have fixed this issue. It appears that configurations linked through plugin.ini aren’t read by neutron when neutron-api runs through Apache. As a result, the new router was set as using a local network instead of GRE tunneling. In our case, moving the configurations to regular neutron.conf fixed the issue. Jean-Philippe Méthot Senior Openstack system administrator Administrateur système Openstack sénior PlanetHoster inc. 4414-4416 Louis B Mayer Laval, QC, H7P 0G1, Canada TEL : +1.514.802.1644 - Poste : 2644 FAX : +1.514.612.0678 CA/US : 1.855.774.4678 FR : 01 76 60 41 43 UK : 0808 189 0423 > Le 18 nov. 2020 à 14:03, Jean-Philippe Méthot a écrit : > > Hi, > > We’ve been running an Openstack setup in production for several years and we upgraded it to Rocky last May. We are now creating a router for a new project for the first time > since that upgrade and we’ve been running into issues with L3HA for that router. Essentially, the router for this project gets initialized with a faulty HA network. > > How do I know it’s faulty? > > -Both Keepalived instances think they are master. > -Both HA network ports get the wrong MTU (9000 instead of 8958) > -Even if I manually set the proper MTU, VRRP packets don’t get received on the other node > -If I then disable and enable the router, MTU gets rolled back to 9000 > -If I force the MTU for this port through the neutron database, it will also get rolled back to 9000 once the router gets recreated > > This setup is using openvswitch and GRE tunnels. I have 7 other projects with L3HA routers running and they do not have this issue, even if I create new routers in them. They are also older projects created before the upgrade to Rocky. This problem is strictly isolated to this new project. > > I’m not sure exactly what’s going on here and why Openstack isn’t taking encapsulation into account when automatically setting its HA network MTU for this. Any suggestion on how to figure out what’s happening behind the scene? > > Jean-Philippe Méthot > Senior Openstack system administrator > Administrateur système Openstack sénior > PlanetHoster inc. > 4414-4416 Louis B Mayer > Laval, QC, H7P 0G1, Canada > TEL : +1.514.802.1644 - Poste : 2644 > FAX : +1.514.612.0678 > CA/US : 1.855.774.4678 > FR : 01 76 60 41 43 > UK : 0808 189 0423 > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdhasman at redhat.com Wed Nov 18 22:31:11 2020 From: rdhasman at redhat.com (Rajat Dhasmana) Date: Thu, 19 Nov 2020 04:01:11 +0530 Subject: Clone Cinder-Backed Image (Ussuri) In-Reply-To: References: Message-ID: Hi Lazuardi, There have been a lot of changes recently in the glance cinder store, the most prominent being support of multiple cinder stores[1] (although that isn't related to your question, still good to know about). If i understand your question correctly, you would like an optimized "create volume from image" operation if the image is volume backed? If yes then we support that as given in the blueprint you mentioned. Also your observation is correct, this is one issue i also noticed while testing out this path and mentioned in the review here[2] (which is a patch to support glance cinder multiple stores functionality) [1] https://specs.openstack.org/openstack/cinder-specs/specs/ussuri/support-glance-multiple-backend.html [2] https://review.opendev.org/#/c/755654/7 Thanks and regards Rajat Dhasmana On Mon, Nov 16, 2020 at 12:17 AM Lazuardi Nasution wrote: > Hi, > > By observation, it seems that if I create a volume from a cinder-backed > image where the new volume host is the same with the cinder host of the > cinder-backed image, the clone is working. Otherwise, the process is > fallback to default. > > Best regards, > > On Mon, Nov 16, 2020 at 1:28 AM Lazuardi Nasution > wrote: > >> Hi, >> >> I have made a cinder-backed image where my cinder is RBD-backed. The >> backing topology of that image is as follows. >> >> glance -> cinder -> RBD. >> >> Is it possible to clone that image like RBD-backed images? I think the >> following bluprint is related but I don't know if it has been >> implemented yet, at least on Ussuri. >> >> >> https://blueprints.launchpad.net/cinder/+spec/clone-image-in-glance-cinder-backend >> >> Best regards, >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gouthampravi at gmail.com Wed Nov 18 23:58:15 2020 From: gouthampravi at gmail.com (Goutham Pacha Ravi) Date: Wed, 18 Nov 2020 15:58:15 -0800 Subject: [manila] Proposing Maari Tamm for python-manilaclient core In-Reply-To: References: Message-ID: On Wed, Nov 18, 2020 at 2:02 PM Victoria Martínez de la Cruz wrote: > > Hi everyone, > > It's a great pleasure for me to propose Maari Tamm (maaritamm) for the python-manilaclient core group. > > Maari joined us as an Outreachy intern working on the manila support for openstackclient in December 2019. She excelled at delivering the main task, and she went above and beyond by continuing to contribute with the community even after her internship finished. She now continues submitting enhancements for the different manila components and taking on new challenges as they appear. > > Not only that, Maari joined us as mentor for the manila project in different efforts we have made: the Open Source Day in Grace Hopper Celebration 2020 and also mentoring for three students from the Boston University that are currently working with us in manila. > > Maari is a truly valuable member of our team and I believe she will be a great addition to the python-manilaclient core reviewers group. > > Looking forward to a positive response. +2 Thank you for this proposal Victoria. Maari's work over the past couple of releases in python-manilaclient is remarkable. It feels absolutely fulfilling as an open source contributor to work alongside a passionate learner who not only harnesses her talent to build things, but also turns around and begins teaching others! > > All the best, > > Victoria From melwittt at gmail.com Thu Nov 19 00:12:05 2020 From: melwittt at gmail.com (melanie witt) Date: Wed, 18 Nov 2020 16:12:05 -0800 Subject: [nova] How best to provide virtio-based input devices? In-Reply-To: <1a1b556fb4c832d15067991741deaedb71c6fbad.camel@redhat.com> References: <1a1b556fb4c832d15067991741deaedb71c6fbad.camel@redhat.com> Message-ID: <3138d040-2d53-059b-2f69-c5a8d0937840@gmail.com> On 11/16/20 02:41, Stephen Finucane wrote: > On Thu, 2020-11-12 at 17:09 -0800, melanie witt wrote: >> Needless to say, I don't like this idea and prefer we took another >> tack >> and kept 'hw_input_bus'  but didn't build on 'hw_pointer_model' and >> instead "deprecated" it. We can't really ever remove the an image >> metadata property, since that would be a breaking upgrade, which >> means >> we'll eventually be left with effectively dead code to maintain >> forever. However, I don't think that's a big deal. >> 'hw_pointer_model=usbtablet' is already on a path to obsolescence as >> the Q35 machine type slowly becomes the default on x86 hosts and the >> use of non-x86 hosts grows since neither support PS2 and must use a >> USB-based input device. In addition, I think the extrapolation of >> 'virtiotablet' to mean also virtio-based keyboard is unclear and >> leaves >> a gaping hole w.r.t. requesting USB-based keyboards on non-AArch64 >> hosts (where it's currently added by default), since we don't >> currently >> do this extrapolation and introducing it would be breaking change on >> x86 hosts (instances would suddenly switch from PS2-based keyboards >> to >> USB-based ones). For some reason your email didn't quote my inline replies when you replied back, so I'm going to label them for clarity. melwitt: > If I understand correctly, we do choose the "best fit" keyboard based > on architecture, independent of the requested hw_pointer_model, today. stephenfin: > Not quite. libvirt on x86 will automatically add a PS2 mouse and > keyboard (even if you request something else) because that's what QEMU > does. On all other platforms (to the best of my knowledge, based on > Kashyap quizzing a handful of multi-arch libvirt devs), this must be > done manually. We currently only do this for AArch64, through the non- > configurable addition of a USB keyboard [1]. There is currently no way > to request e.g. a USB or virtio keyboard on any architecture. > > [1] https://github.com/openstack/nova/commit/b92e3bc95fd Hm, OK, apologies for my lack of familiarity here. So there are really three things here: tablet, mouse, and keyboard. And the user today can choose hw_pointer_model as None (leave it to default behavior) or usbtablet which sets the input.type=tablet and the input.bus=usb. And then the mouse and keyboard are set to whatever they have to be given the architecture. melwitt: > It feels like it would be simpler to continue doing that and add a > virtio choice to hw_pointer_model and let the driver pick the "best" > keyboard to go along with that. Is it your view that having the >> driver choose a virtio keyboard if hw_pointer_model=virtiotablet is >> inconsistent with the existing "best fit" keyboard selection >> behavior? stephenfin: > My concerns are twofold. Firstly, having the value of > 'hw_pointer_model' influence the keyboard bus is poor UX, since this > "feature" is not at all apparent from the property name. Secondly, > 'hw_pointer_model' is a poorly designed property, given it configured > the bus as well as the model, munging the two. > > To be clear, I agree that having different buses for keyboard and > pointer makes no sense. There's no reason they shouldn't be the same. > I'm just saying that configuring the bus for input devices via an > appropriately named 'hw_input_bus' image metadata property makes much > more sense that maybe getting one configured magically based on the > "pointer model" in use. OK, so the introduction of virtio would be the first time that we would be able to set all of tablet, mouse, and keyboard to the same bus. What if they don't want all three input devices, could it cause any undesirable behavior for them? And then if they set hw_input_bus=usb for libvirt on x86 they'd get a USB tablet, a PS2 mouse, and a PS2 keyboard and on AArch64 they'd get a USB tablet, ? mouse, and USB keyboard. I dunno, it's all pretty confusing IMHO. My point in my last reply was that for the libvirt on x86 case, if the user sets hw_input_bus=usb, how would they know they're really only specifying the tablet? Today they use hw_pointer_model=usbtablet which makes it clear what they have control over. I acknowledge that for hw_input_bus=virtio, things all line up nicely, but for everything else, it doesn't necessarily. This makes me think it would be clearest and least confusing (IMHO) to add a new option like dansmith mentioned, hw_pointer_model=virtio. That way it's not talking only about a tablet but generically just 'virtio' and then all of tablet, mouse, and keyboard get added with bus=virtio. melwitt: > From what I understand, the pointer is the only user selection we can guarantee and the keyboard is architecture dependent. stephenfin: > Again, not really. There isn't an analog for pointer vs. mouse when it > comes to keyboards. The keyboard isn't architecture dependent. What is > architecture dependent is whether you get a keyboard and mouse by > default (yes on x86, in the form of a PS2 mouse and keyboard, and no > for everyone else). melwitt: >> If we "deprecated" hw_pointer_model and introduced hw_input_bus, how does >> the user know which thing (pointer or keyboard) they are specifying? >> If users can't actually choose the keyboard and can only choose the pointer, > wouldn't presenting a selection of a generic "hw_input_bus" be more confusing >> than hw_pointer_model? stephenfin: > They can choose the _bus_ that the keyboard uses. There's an assumption > here that if you request a graphics device (VNC, SPICE, ...) then you > will get a keyboard and tablet input devices, because that graphics > device is unusable otherwise. There is also an assumption (based on > dansmith's comments about mouse being only used for legacy compat > reasons) that the user will never want to explicitly request a 'mouse' > pointer model and should therefore get 'tablet' by default. Based on > these two assumptions, the only thing remaining is to decide how the > keyboard and tablet devices will be attached to the guest...achieved > via a sensibly named 'hw_input_bus' image metadata property. That seems > reasonable to me. I hope I'm not woefully wrong here again, but IIUC they can't choose the bus the mouse and keyboard uses for libvirt on x86, they get PS2 regardless. This is why I feel like hw_input_bus as a replacement for hw_pointer_model is not clear. It's only guaranteed to be used for the tablet bus. I'm sorry I'm not seeing how hw_pointer_model=virtio isn't the clearest, least confusing way to add virtio. (Or maybe hw_pointer_model=virtiotabletmousekeyboard ?!) Thanks for taking the time to explain the technical details around this area of the code. I think I now understand your point of view since the name of hw_pointer_model doesn't nicely convey the tablet+mouse+keyboard setting when it comes to virtio. On the flip side of that, I feel like hw_input_bus=usb when it's only going to be honored for the tablet for libvirt on x86 seems even less nice. This is all just MHO. If most other people think that hw_input_bus is the clearer and more user-friendly way to present this config, then I will of course accept the consensus. Cheers, -melanie >> We need to decide what approach to go for before I rework this. If >> anyone has input, particularly operators that think they'd use this >> feature, I'd love to hear it so that I can t̶e̶l̶l̶ ̶d̶a̶n̶s̶m̶i̶t̶h̶ >> ̶t̶o̶ ̶s̶h̶o̶v̶e̶ ̶i̶t̶ come to the best possible solution ;-) Feel >> free to either reply here or on the review [1]. >> >> Cheers, >> Stephen >> >> [1] https://review.opendev.org/#/c/756552/ >> >> > > > From tpb at dyncloud.net Thu Nov 19 00:37:19 2020 From: tpb at dyncloud.net (Tom Barron) Date: Wed, 18 Nov 2020 19:37:19 -0500 Subject: [manila] Proposing Maari Tamm for python-manilaclient core In-Reply-To: References: Message-ID: <20201119003719.osbliwcdjq7x2xl7@barron.net> On 18/11/20 18:52 -0300, Victoria Martínez de la Cruz wrote: >Hi everyone, > >It's a great pleasure for me to propose Maari Tamm (maaritamm) for the >python-manilaclient core group. > >Maari joined us as an Outreachy intern working on the manila support for >openstackclient in December 2019. She excelled at delivering the main task, >and she went above and beyond by continuing to contribute with the >community even after her internship finished. She now continues submitting >enhancements for the different manila components and taking on new >challenges as they appear. > >Not only that, Maari joined us as mentor for the manila project in >different efforts we have made: the Open Source Day in Grace Hopper >Celebration 2020 and also mentoring for three students from the Boston >University that are currently working with us in manila. > >Maari is a truly valuable member of our team and I believe she will be a >great addition to the python-manilaclient core reviewers group. > >Looking forward to a positive response. > >All the best, > >Victoria Very positive response from me! -- Tom From amy at demarco.com Thu Nov 19 00:42:55 2020 From: amy at demarco.com (Amy Marrich) Date: Wed, 18 Nov 2020 18:42:55 -0600 Subject: [manila] Proposing Maari Tamm for python-manilaclient core In-Reply-To: References: Message-ID: My vote doesn't count but +1. Maari was great at GHC! Amy (spotz) On Wed, Nov 18, 2020 at 3:55 PM Victoria Martínez de la Cruz < victoria at vmartinezdelacruz.com> wrote: > Hi everyone, > > It's a great pleasure for me to propose Maari Tamm (maaritamm) for the > python-manilaclient core group. > > Maari joined us as an Outreachy intern working on the manila support for > openstackclient in December 2019. She excelled at delivering the main task, > and she went above and beyond by continuing to contribute with the > community even after her internship finished. She now continues submitting > enhancements for the different manila components and taking on new > challenges as they appear. > > Not only that, Maari joined us as mentor for the manila project in > different efforts we have made: the Open Source Day in Grace Hopper > Celebration 2020 and also mentoring for three students from the Boston > University that are currently working with us in manila. > > Maari is a truly valuable member of our team and I believe she will be a > great addition to the python-manilaclient core reviewers group. > > Looking forward to a positive response. > > All the best, > > Victoria > -------------- next part -------------- An HTML attachment was scrubbed... URL: From viroel at gmail.com Thu Nov 19 00:57:48 2020 From: viroel at gmail.com (Douglas) Date: Wed, 18 Nov 2020 21:57:48 -0300 Subject: [manila] Proposing Maari Tamm for python-manilaclient core In-Reply-To: References: Message-ID: A big +1 from me. Em qua, 18 de nov de 2020 18:54, Victoria Martínez de la Cruz < victoria at vmartinezdelacruz.com> escreveu: > Hi everyone, > > It's a great pleasure for me to propose Maari Tamm (maaritamm) for the > python-manilaclient core group. > > Maari joined us as an Outreachy intern working on the manila support for > openstackclient in December 2019. She excelled at delivering the main task, > and she went above and beyond by continuing to contribute with the > community even after her internship finished. She now continues submitting > enhancements for the different manila components and taking on new > challenges as they appear. > > Not only that, Maari joined us as mentor for the manila project in > different efforts we have made: the Open Source Day in Grace Hopper > Celebration 2020 and also mentoring for three students from the Boston > University that are currently working with us in manila. > > Maari is a truly valuable member of our team and I believe she will be a > great addition to the python-manilaclient core reviewers group. > > Looking forward to a positive response. > > All the best, > > Victoria > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkajinam at redhat.com Thu Nov 19 03:14:20 2020 From: tkajinam at redhat.com (Takashi Kajinami) Date: Thu, 19 Nov 2020 12:14:20 +0900 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: Message-ID: > So, I wanted to clarify something that came out of the IRC discussion, > which is "do it like devstack". When we say that, or at least when *I* > said it, we meant "have different config files for each service so that > you can get the config elements appropriate for each service set > correctly." I have one concern with the way we generate the default config, if we expect separated config files. Currently in most of the distros we use oslo-config-generator to render the default conf file. Since oslo-config-generator rendors all config options implemented in nova, we don't have any good way to generate the sample config file for each service. We didn't care which file we put the option since all services use the single file, but now we should always refer to that documentation unless we implement generation of service-specific files or we write down the services requiring that option in parameter description. # We have the same problem with nova-db.conf approach. > Despite the fact that nobody *should* be setting these credentials in > their config file, we know that at in least some circumstances, they > are. TripleO is setting them (always I think?) because puppet-nova does > that. ... The issue with TripleO was fixed by the change in puppet-nova[1], and nova.conf for nova-compute service no longer includes database credentials. We can backport the fix is needed, as per discussion with owalsh on the previous mails. [1] https://review.opendev.org/#/c/755689/ But from puppet-nova's perspective the sandalone deployment or ironic deployment(*1) still needs some fix to address the separate config files, because all processes run on host, not on container, and refer to the same default conf file, nova.conf. Since puppet-nova follows the way how distro packaging provides the default config files, we need to fix current implementation in puppet-nova after each distro packages provide the updated version with new config file structure. (*1) In usual deployment with ironic, we have nova-compute running on the controller nodes, where nova-api is also running, IIUC. On Thu, Nov 19, 2020 at 4:27 AM Dan Smith wrote: > > There was a long discussion on #openstack-nova today[3] around this > > topic. So you can find more detailed reasoning there[3]. > > I just had a long voice chat with Ollie about this, trying to understand > some of the challenges that still exist with some of the things we've > discussed and the proposed forward steps. > > There are lots of things to clarify, I think, and we could honestly > probably use a wider voice chat among the people that need to work on > this. However, I'll try here. > > First off, I want to address the "do it like devstack" recommendation, > and the subsequent suggestion of standardizing on something like a > "nova-db.conf" file arrangement to keep the db credentials in one > place. As Ollie has pointed out, devstack doesn't support all the > various deployment arrangements (such as "one metadata api per cell") > and thus doesn't have a prescription for how to arrange the config files > in those scenarios. Specifically, an all-in-one deployment that includes > multiple API services with different configs would currently have to hack > around the hardcoded nova.conf file with the environment variable that > allows them to specify a directory other than /etc/nova.conf. Devstack > doesn't have to do this because it doesn't support that arrangement of > services, but if it did, it would have to. > > So, I wanted to clarify something that came out of the IRC discussion, > which is "do it like devstack". When we say that, or at least when *I* > said it, we meant "have different config files for each service so that > you can get the config elements appropriate for each service set > correctly." That doesn't mean "nova-compute should point to > /etc/nova/nova-cpu.conf because that's what devstack does". Especially > in a containerized setup, I would expect everything to use > /etc/nova/nova.conf, since those are namespaced per-service because of > the containerization. Further, just because devstack doesn't run a > metadata per cell (or any other such optional arrangement), obviously > that doesn't mean you can't. > > That leads me to the first action item I think we need: > > ACTION 1: Make the wsgi app able to use something other than nova.conf > > All of our other services support a --config-file flag, and I don't see > why we wouldn't allow this if it's necessary for deployments. In the > pure API arrangement, it shouldn't really be necessary to change this, > but clearly you may need to have multiple API workers with different > configs, as is the case with metadata-per-cell, or even potentially some > admin-focused private API endpoint. If it makes it easier for deployment > tools to start the API workers with a specific config file, we should > let them do that. You can already work around that hard-coded filename > by setting OS_NOVA_CONFIG_DIR to something other than /etc/nova, but we > shouldn't require them to create directories just to have separate > configs. > > The next item is related: > > ACTION 2: We need to document a minimal viable config for each service > > Ollie points out that, obviously, handing the deployer a config > reference with 1.21 bajillion config options does not clearly indicate > which services need which thing, and especially, which things are > _not_allowed_ to be set for a service (such as db credentials on the > compute). We can't feasibly audit every config option we have, but it > would be very helpful to have a reference that shows what a completely > minimal configuration for each service looks like. We could do that by > tagging services per config options (which I suggested earlier, and > would still be good) but I think maybe a standalone document would be > easier for people to follow. > > Now, on to the question about the hard-fail patch for compute: > > https://review.opendev.org/#/c/762176/ > > The Nova devs have wanted people to _not_ have db credentials in the > config file that nova-compute can see for a "Very Long Time." We have > even made some assumptions in the code that rely on these credentials > being not set on the compute, which is at least partially why we're > having this conversation (again) now. > > Despite the fact that nobody *should* be setting these credentials in > their config file, we know that at in least some circumstances, they > are. TripleO is setting them (always I think?) because puppet-nova does > that. OSA has said that they're setting them somewhat incidentally when > they do all-in-one deployments. The latter is unlikely to affect any > real deployments, but the former definitely _will_, and anyone else that > isn't present in this discussion may be including credentials > unnecessarily, which we will break when we merge that patch. Thus, I > think that, even though it feels long overdue for devs, the most prudent > and cautious approach will be to: > > ACTION 3: Not merge that hard fail until X > > We have the warning, we have the reno. We expect that the deployment > tools will be working to eliminate the credentials for the compute > config, but merging that will make it an emergency for them. We've > waited years at this point, we can wait one more cycle for safety. As > Ollie pointed out, we've not been super clear about messaging this, > despite it being a well-worn assumption amongst the developers for a > long time. > > To aid in smoking out any of the jobs or configs that deployment tools > may still have which will break when we merge that patch, we should also > consider: > > ACTION 4: A workaround flag to opt-in to the strict checking > > Basically, this would be a one or two-cycle workaround, which when > enabled, would opt-in to the (above) behavior of causing compute to fail > on startup if db credentials are present. This would allow the > deployment tool maintainers, as well as people responsible for CI jobs > to smoke test the new behavior early, before we merge it and cause an > emergency for them. We can set this as on by default in our devstack > jobs to signal that it is good with the new behavior, and also encourage > the other deployment projects to set it as well once they're generating > clean configs for their nova-computes. Once we merge the patch to > actually fail all the time, we can remove this workaround config, > according to the original intent of the workarounds group, that those > flags are short-lived. > > We could do this by altering gibi's patch to only fail if the workaround > is enabled, and then follow up in X by removing the workaround check. > > So, I know that was a lot of words, but I think if we can agree to the > above four items, we'll have a path forward that doesn't overly burden > any one specific group while still allowing us to chart a path to > getting where we want to be. > > I think we need acks from a bunch of groups, probably at least: > > - Nova (gibi, stephenfin) > - TripleO (owalsh) > - Debian (zigo) > - Kolla (yoctozepto) > - OSA (noonedeadpunk) > - rdo-ci (jpena) > - puppet-nova (tkajinam) > > Are people okay with these action items? > > --Dan > > -- ---------- Takashi Kajinami Senior Software Maintenance Engineer Customer Experience and Engagement Red Hat e-mail: tkajinam at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From yingjisun at vmware.com Thu Nov 19 05:56:43 2020 From: yingjisun at vmware.com (Yingji Sun) Date: Thu, 19 Nov 2020 05:56:43 +0000 Subject: Ask a question about nova console Message-ID: <006521C6-A96E-41D5-BCE9-5398751546A8@vmware.com> Buddies, I hit an issue on nova console. In vm console, it only handles keyboard event, but not mouse event. That is I can only use keyboard in the vm, but not mouse. The backend is vsphere. I can use both keyboard and mouse through vsphere remote console. So where does the issue likely hide ? Is there any option in nova configure file that relates to this issue ? Any feedback would be appreciated. Yingji. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yingjisun at vmware.com Thu Nov 19 06:34:59 2020 From: yingjisun at vmware.com (Yingji Sun) Date: Thu, 19 Nov 2020 06:34:59 +0000 Subject: Ask a question about nova console In-Reply-To: <006521C6-A96E-41D5-BCE9-5398751546A8@vmware.com> References: <006521C6-A96E-41D5-BCE9-5398751546A8@vmware.com> Message-ID: <15115145-9A2A-488C-8D42-F6F4A74EA212@vmware.com> And new findings, I have to press ctrl key first then the vm can take the mouse event. After a while, vm does not take the mouse event any more. If I want to use mouse, I need to press ctrl key again. Another issue is that the caplock does not work either in the vm. Yingji. > > Buddies, > > I hit an issue on nova console. > In vm console, it only handles keyboard event, but not mouse event. That is I can only use keyboard in the vm, but not mouse. > The backend is vsphere. I can use both keyboard and mouse through vsphere remote console. > So where does the issue likely hide ? Is there any option in nova configure file that relates to this issue ? > > Any feedback would be appreciated. > > Yingji. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noonedeadpunk at ya.ru Thu Nov 19 08:04:21 2020 From: noonedeadpunk at ya.ru (Dmitriy Rabotyagov) Date: Thu, 19 Nov 2020 10:04:21 +0200 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: Message-ID: <7941321605772116@mail.yandex.ru> An HTML attachment was scrubbed... URL: From mark at stackhpc.com Thu Nov 19 10:41:59 2020 From: mark at stackhpc.com (Mark Goddard) Date: Thu, 19 Nov 2020 10:41:59 +0000 Subject: [cinder] Ceph, active-active and no coordination In-Reply-To: <20201118093259.k6hjbjfbc6eomymg@localhost> References: <20201118093259.k6hjbjfbc6eomymg@localhost> Message-ID: On Wed, 18 Nov 2020 at 09:33, Gorka Eguileor wrote: > > On 17/11, Giulio Fidente wrote: > > I am leaving some comments inline and adding on CC some cinder folks who > > know better > > > > On 11/17/20 9:27 PM, Radosław Piliszek wrote: > > > Dear Cinder Masters, > > > > > > I have a question for you. (or two, or several; well, actually the > > > whole Kolla team has :-) ) > > > > > > The background is that Kolla has been happily deploying multinode > > > cinder-volume with Ceph RBD backend, with no coordination configured, > > > cluster parameter unset, host properly set per host and backend_host > > > normalised (as well as any other relevant config) between the > > > cinder-volume hosts. > > > > > > The first question is: do we correctly understand that this was an > > > active-active deployment? Or really something else? > > Hi, > > That is an Active-Active deployment with an Active-Passive > configuration, so it's a PROBLEM waiting to happen. > > Besides races that could happen in the code because there is no > coordinator configured (this is less of an issue for the RBD driver than > for other drivers, but it's still an issue), there's also a problem > whenever a cinder-volume service starts. > > Any time a cinder-volume service starts it will mess many of the > resources that are being worked on (those with status ending in 'ing', > such as 'creating') because it thinks those are resources that it left > in that state and need to be cleaned. > > My recommendation is to do this right: configure the cluster option, > remove the backend_host, and configure the coordinator. Upgrading a > deployment from that configuration to clustered is relatively easy, we > just need to leave one of the cinder-volume services with the > backend_host as it was before; that way when it starts it will > automatically migrate all the resources from being non-clustered to > being clustered (an alternative would be to add this command to > cinder-manage, because I don't think the current "cinder-manage cluster > rename" will work). > > If deploying the coordinator is an issue, we should at least do the > other 2 steps. That way we'll get rid of the cleanup issue even if we > still have the race conditions. Thank you for the recommendation, Gorka. I think we are now agreed that this is the right way forward - set cluster, and strongly recommend a coordinator (we configure one already if the user has enabled etcd or redis). We identified 3 cases to consider. 1. Train deployments with backend_host configured as per documentation 2. Ussuri deployments with backend_host configured, due to upgrade from Train. 3. Ussuri deployments without backend_host configured, either due to a fresh Ussuri deployment or a Train upgrade followed by removal of documented backend_host configuration in favour of new Kolla Ansible defaults. We need to consider both minor and major upgrades that apply whatever changes we come up with. > > Cheers, > Gorka. > > > > > this configuration is similar to that deployed by tripleo, except > > tripleo would use pacemaker to have always a single cinder-volume running > > > > the reason being that, as far as I understand, without a coordinator the > > first cinder-volume within a given 'backend_host' group to consume the > > message from the amqp queue will start executing the task ... so if > > another task is queued (or is in progress), for the same volume, there > > is risk of data corruption > > > > > Now, there have been no reports that it misbehaved for anyone. It > > > certainly has not for any Kolla core. The fact is it was brought to > > > our attention because due to the drop of Kolla-deployed Ceph, the > > > recommendation to set backend_host was not present and users tripped > > > over non-uniform backend_host. And this is expected, of course. > > > > > > The second and final question is, building up on the first one, were > > > we doing it wrong all the time? > > > (plus extras: Why did it work? Were there any quirks? What should we do?) > > I think the correct setup for active/active should be > > > > - do not use same host or backend_host > > - do set cluster to same value across cluster members > > - use a coordinator > > > > > PS: Please let me know if this thought process is actually > > > Ceph-independent as well. > > I don't think it's Ceph dependent, my understanding is that > > active/active is only possible with some drivers because not every > > driver is safe to use in active/active configuration; some can, for > > example, have issues handling the database > > > > Ceph is just one of those drivers which behaves correctly in > > active/active configuration > > -- > > Giulio Fidente > > GPG KEY: 08D733BA > > > > From ces.eduardo98 at gmail.com Thu Nov 19 10:44:34 2020 From: ces.eduardo98 at gmail.com (Carlos Silva) Date: Thu, 19 Nov 2020 07:44:34 -0300 Subject: [manila] Proposing Maari Tamm for python-manilaclient core In-Reply-To: References: Message-ID: +1! Maari has been doing a great work on python-manilaclient! Em qua., 18 de nov. de 2020 às 18:55, Victoria Martínez de la Cruz < victoria at vmartinezdelacruz.com> escreveu: > Hi everyone, > > It's a great pleasure for me to propose Maari Tamm (maaritamm) for the > python-manilaclient core group. > > Maari joined us as an Outreachy intern working on the manila support for > openstackclient in December 2019. She excelled at delivering the main task, > and she went above and beyond by continuing to contribute with the > community even after her internship finished. She now continues submitting > enhancements for the different manila components and taking on new > challenges as they appear. > > Not only that, Maari joined us as mentor for the manila project in > different efforts we have made: the Open Source Day in Grace Hopper > Celebration 2020 and also mentoring for three students from the Boston > University that are currently working with us in manila. > > Maari is a truly valuable member of our team and I believe she will be a > great addition to the python-manilaclient core reviewers group. > > Looking forward to a positive response. > > All the best, > > Victoria > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Thu Nov 19 11:09:05 2020 From: hberaud at redhat.com (Herve Beraud) Date: Thu, 19 Nov 2020 12:09:05 +0100 Subject: [oslo] following or not following the DST changes for our meeting time In-Reply-To: References: Message-ID: Hi Moises, Thanks for details. I let this topic open for discussion for a few days again to allow everybody to react, next week I'll officialize it if nobody complains about it. Le mer. 18 nov. 2020 à 13:55, Moises Guimaraes de Medeiros < moguimar at redhat.com> a écrit : > Hi Hervé, > > Historically, Oslo team meeting has been at 1500 UTC, which translates to > 3PM UTC, > I think the discussed proposal in the oslo irc meeting was 1500 UTC with > DST and > 1600 UTC without DST, which translates to 3PM UTC and 4PM UTC accordingly. > > I other words, that means that we should move the slot from 1500 UTC to > 1600 UTC > with the recent time change. > > On Mon, Nov 16, 2020 at 2:51 PM Herve Beraud wrote: > >> Hello Oslofolk, >> >> As discussed during our previous meeting, at each DST change, the agenda >> of some of us conflicting with our Oslo meeting time slot, this thread just >> wants to propose a solution to avoid that. >> >> We could just move our meeting time when DST changes, and then move back >> to this slot once DST is back. >> >> Right now our meeting time is UTC based, we suppose that UTC is required >> because of the OpenStack meeting tooling. >> >> By following that we will get the following time slots: >> >> - meeting time slot when DST start: 5:00pm UTC >> >> - meeting time slot when DST end: 4:00pm UTC >> >> Does it fit well for you? >> >> -- >> Hervé Beraud >> Senior Software Engineer at Red Hat >> irc: hberaud >> https://github.com/4383/ >> https://twitter.com/4383hberaud >> -----BEGIN PGP SIGNATURE----- >> >> wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ >> Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ >> RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP >> F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G >> 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g >> glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw >> m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ >> hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 >> qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y >> F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 >> B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O >> v6rDpkeNksZ9fFSyoY2o >> =ECSj >> -----END PGP SIGNATURE----- >> >> > > -- > > Moisés Guimarães > > Software Engineer > > Red Hat > > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From eyle.brinkhuis at surf.nl Thu Nov 19 12:00:50 2020 From: eyle.brinkhuis at surf.nl (Eyle Brinkhuis) Date: Thu, 19 Nov 2020 12:00:50 +0000 Subject: NUMATopologyFilter and AMD Epyc Rome Message-ID: <721C093E-A340-4EA2-A56F-8D704B1343B9@surf.nl> Hi all, We’re running into an issue with deploying our infrastructure to run high throughput, low latency workloads. Background: We run Lenovo SR635 systems with an AMD Epyc 7502P processor. In the BIOS of this system, we are able to define the amount of NUMA cells per socket (called NPS). We can set 1, 2 or 4. As we run a 2x 100Gbit/s Mellanox CX5 in this system as well, we use the preferred-io setting in the BIOS to give preferred io throughput to the Mellanox CX5. To make sure we get as high performance as possible, we set the NPS setting to 1, resulting in a single numa cell with 64 CPU threads available. Next, in Nova (train distribution), we demand huge pages. Hugepages however, demands a NUMAtopology, but as this is one large NUMA cell, even with cpu=dedicated or requesting a single numa domain, we fail: compute03, compute03 fails NUMA topology requirements. No host NUMA topology while the instance specified one. host_passes /usr/lib/python3/dist-packages/nova/scheduler/filters/numa_topology_filter.py:119 Any idea how to counter this? Setting NPS-2 will create two NUMA domains, but also cut our performance way down. Thanks! Regards, Eyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at est.tech Thu Nov 19 12:07:58 2020 From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer) Date: Thu, 19 Nov 2020 13:07:58 +0100 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: Message-ID: On Wed, Nov 18, 2020 at 11:24, Dan Smith wrote: >> There was a long discussion on #openstack-nova today[3] around this >> topic. So you can find more detailed reasoning there[3]. > > I just had a long voice chat with Ollie about this, trying to > understand > some of the challenges that still exist with some of the things we've > discussed and the proposed forward steps. Thank you Dan for pushing this forward. > > There are lots of things to clarify, I think, and we could honestly > probably use a wider voice chat among the people that need to work on > this. However, I'll try here. > > First off, I want to address the "do it like devstack" recommendation, > and the subsequent suggestion of standardizing on something like a > "nova-db.conf" file arrangement to keep the db credentials in one > place. As Ollie has pointed out, devstack doesn't support all the > various deployment arrangements (such as "one metadata api per cell") > and thus doesn't have a prescription for how to arrange the config > files > in those scenarios. Specifically, an all-in-one deployment that > includes > multiple API services with different configs would currently have to > hack > around the hardcoded nova.conf file with the environment variable that > allows them to specify a directory other than /etc/nova.conf. Devstack > doesn't have to do this because it doesn't support that arrangement of > services, but if it did, it would have to. > > So, I wanted to clarify something that came out of the IRC discussion, > which is "do it like devstack". When we say that, or at least when *I* > said it, we meant "have different config files for each service so > that > you can get the config elements appropriate for each service set > correctly." That doesn't mean "nova-compute should point to > /etc/nova/nova-cpu.conf because that's what devstack does". Especially > in a containerized setup, I would expect everything to use > /etc/nova/nova.conf, since those are namespaced per-service because of > the containerization. Further, just because devstack doesn't run a > metadata per cell (or any other such optional arrangement), obviously > that doesn't mean you can't. > > That leads me to the first action item I think we need: > > ACTION 1: Make the wsgi app able to use something other than nova.conf > > All of our other services support a --config-file flag, and I don't > see > why we wouldn't allow this if it's necessary for deployments. In the > pure API arrangement, it shouldn't really be necessary to change this, > but clearly you may need to have multiple API workers with different > configs, as is the case with metadata-per-cell, or even potentially > some > admin-focused private API endpoint. If it makes it easier for > deployment > tools to start the API workers with a specific config file, we should > let them do that. You can already work around that hard-coded filename > by setting OS_NOVA_CONFIG_DIR to something other than /etc/nova, but > we > shouldn't require them to create directories just to have separate > configs. I will look into this change and propose patch a patch. > > The next item is related: > > ACTION 2: We need to document a minimal viable config for each service > > Ollie points out that, obviously, handing the deployer a config > reference with 1.21 bajillion config options does not clearly indicate > which services need which thing, and especially, which things are > _not_allowed_ to be set for a service (such as db credentials on the > compute). We can't feasibly audit every config option we have, but it > would be very helpful to have a reference that shows what a completely > minimal configuration for each service looks like. We could do that by > tagging services per config options (which I suggested earlier, and > would still be good) but I think maybe a standalone document would be > easier for people to follow. I've opened a doc bug to track the minimal config documentation work: https://bugs.launchpad.net/nova/+bug/1904179 But I would like to get help from others to start proposing this doc. > > Now, on to the question about the hard-fail patch for compute: > > https://review.opendev.org/#/c/762176/ > > The Nova devs have wanted people to _not_ have db credentials in the > config file that nova-compute can see for a "Very Long Time." We have > even made some assumptions in the code that rely on these credentials > being not set on the compute, which is at least partially why we're > having this conversation (again) now. > > Despite the fact that nobody *should* be setting these credentials in > their config file, we know that at in least some circumstances, they > are. TripleO is setting them (always I think?) because puppet-nova > does > that. OSA has said that they're setting them somewhat incidentally > when > they do all-in-one deployments. The latter is unlikely to affect any > real deployments, but the former definitely _will_, and anyone else > that > isn't present in this discussion may be including credentials > unnecessarily, which we will break when we merge that patch. Thus, I > think that, even though it feels long overdue for devs, the most > prudent > and cautious approach will be to: > > ACTION 3: Not merge that hard fail until X > > We have the warning, we have the reno. We expect that the deployment > tools will be working to eliminate the credentials for the compute > config, but merging that will make it an emergency for them. We've > waited years at this point, we can wait one more cycle for safety. As > Ollie pointed out, we've not been super clear about messaging this, > despite it being a well-worn assumption amongst the developers for a > long time. I'm OK not to merge the breaking patch in W. > > To aid in smoking out any of the jobs or configs that deployment tools > may still have which will break when we merge that patch, we should > also > consider: > > ACTION 4: A workaround flag to opt-in to the strict checking > > Basically, this would be a one or two-cycle workaround, which when > enabled, would opt-in to the (above) behavior of causing compute to > fail > on startup if db credentials are present. This would allow the > deployment tool maintainers, as well as people responsible for CI jobs > to smoke test the new behavior early, before we merge it and cause an > emergency for them. We can set this as on by default in our devstack > jobs to signal that it is good with the new behavior, and also > encourage > the other deployment projects to set it as well once they're > generating > clean configs for their nova-computes. Once we merge the patch to > actually fail all the time, we can remove this workaround config, > according to the original intent of the workarounds group, that those > flags are short-lived. > > We could do this by altering gibi's patch to only fail if the > workaround > is enabled, and then follow up in X by removing the workaround check. I will make the suggested changes in my patch. > > So, I know that was a lot of words, but I think if we can agree to the > above four items, we'll have a path forward that doesn't overly burden > any one specific group while still allowing us to chart a path to > getting where we want to be. > > I think we need acks from a bunch of groups, probably at least: > > - Nova (gibi, stephenfin) > - TripleO (owalsh) > - Debian (zigo) > - Kolla (yoctozepto) > - OSA (noonedeadpunk) > - rdo-ci (jpena) > - puppet-nova (tkajinam) > > Are people okay with these action items? I'm on OK with this direction. Cheers, gibi > > --Dan From stephenfin at redhat.com Thu Nov 19 12:25:46 2020 From: stephenfin at redhat.com (Stephen Finucane) Date: Thu, 19 Nov 2020 12:25:46 +0000 Subject: NUMATopologyFilter and AMD Epyc Rome In-Reply-To: <721C093E-A340-4EA2-A56F-8D704B1343B9@surf.nl> References: <721C093E-A340-4EA2-A56F-8D704B1343B9@surf.nl> Message-ID: <3635f14885abcb71cf313c1ca81f721920644cc9.camel@redhat.com> On Thu, 2020-11-19 at 12:00 +0000, Eyle Brinkhuis wrote: > Hi all, > > We’re running into an issue with deploying our infrastructure to run > high throughput, low latency workloads. > > Background: > > We run Lenovo SR635 systems with an AMD Epyc 7502P processor. In the > BIOS of this system, we are able to define the amount of NUMA cells > per socket (called NPS). We can set 1, 2 or 4. As we run a 2x > 100Gbit/s Mellanox CX5 in this system as well, we use the preferred- > io setting in the BIOS to give preferred io throughput to the > Mellanox CX5. > To make sure we get as high performance as possible, we set the NPS > setting to 1, resulting in a single numa cell with 64 CPU threads > available. > > Next, in Nova (train distribution), we demand huge pages. Hugepages > however, demands a NUMAtopology, but as this is one large NUMA cell, > even with cpu=dedicated or requesting a single numa domain, we fail: > > compute03, compute03 fails NUMA topology requirements. No host NUMA > topology while the instance specified one. host_passes > /usr/lib/python3/dist- > packages/nova/scheduler/filters/numa_topology_filter.py:119 Oh, this is interesting. This would suggest that when NPS is configured to 1, the host is presented as a UMA system and libvirt doesn't present topology information for us to parse. That seems odd and goes against how I though newer versions of libvirt worked. What do you see for when you run e.g.: $ virsh capabilities | xmllint --xpath '/capabilities/host/topology' - > Any idea how to counter this? Setting NPS-2 will create two NUMA > domains, but also cut our performance way down. It's worth noting that by setting NP1 to 1, you're already cutting your performance. This makes it look like you've got a single NUMA node but of course, that doesn't change the physical design of the chip and there are still multiple memory controllers, some of which will be slower to access to from certain cores. You're simply mixing best and worst case performance to provide an average. You said you have two SR- IOV NICs. I assume you're bonding these NICs? If not, you could set NPS to 2 and then ensure the NICs are in PCI slots that correspond to different NUMA nodes. You can validate this configuration using tools like 'lstopo' and 'numactl'. Stephen > Thanks! > > Regards, > > Eyle > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vhariria at redhat.com Thu Nov 19 12:30:30 2020 From: vhariria at redhat.com (Vida Haririan) Date: Thu, 19 Nov 2020 07:30:30 -0500 Subject: [manila] Proposing Maari Tamm for python-manilaclient core In-Reply-To: References: Message-ID: A big +1! for Maari's contributions to python-manilaclient On Thu, Nov 19, 2020 at 5:49 AM Carlos Silva wrote: > +1! > Maari has been doing a great work on python-manilaclient! > > Em qua., 18 de nov. de 2020 às 18:55, Victoria Martínez de la Cruz < > victoria at vmartinezdelacruz.com> escreveu: > >> Hi everyone, >> >> It's a great pleasure for me to propose Maari Tamm (maaritamm) for the >> python-manilaclient core group. >> >> Maari joined us as an Outreachy intern working on the manila support for >> openstackclient in December 2019. She excelled at delivering the main task, >> and she went above and beyond by continuing to contribute with the >> community even after her internship finished. She now continues submitting >> enhancements for the different manila components and taking on new >> challenges as they appear. >> >> Not only that, Maari joined us as mentor for the manila project in >> different efforts we have made: the Open Source Day in Grace Hopper >> Celebration 2020 and also mentoring for three students from the Boston >> University that are currently working with us in manila. >> >> Maari is a truly valuable member of our team and I believe she will be a >> great addition to the python-manilaclient core reviewers group. >> >> Looking forward to a positive response. >> >> All the best, >> >> Victoria >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephenfin at redhat.com Thu Nov 19 12:31:28 2020 From: stephenfin at redhat.com (Stephen Finucane) Date: Thu, 19 Nov 2020 12:31:28 +0000 Subject: NUMATopologyFilter and AMD Epyc Rome In-Reply-To: <3635f14885abcb71cf313c1ca81f721920644cc9.camel@redhat.com> References: <721C093E-A340-4EA2-A56F-8D704B1343B9@surf.nl> <3635f14885abcb71cf313c1ca81f721920644cc9.camel@redhat.com> Message-ID: On Thu, 2020-11-19 at 12:25 +0000, Stephen Finucane wrote: > On Thu, 2020-11-19 at 12:00 +0000, Eyle Brinkhuis wrote: > > Hi all, > > > > We’re running into an issue with deploying our infrastructure to > > run high throughput, low latency workloads. > > > > Background: > > > > We run Lenovo SR635 systems with an AMD Epyc 7502P processor. In > > the BIOS of this system, we are able to define the amount of NUMA > > cells per socket (called NPS). We can set 1, 2 or 4. As we run a 2x > > 100Gbit/s Mellanox CX5 in this system as well, we use the > > preferred-io setting in the BIOS to give preferred io throughput to > > the Mellanox CX5. > > To make sure we get as high performance as possible, we set the NPS > > setting to 1, resulting in a single numa cell with 64 CPU threads > > available. > > > > Next, in Nova (train distribution), we demand huge pages. Hugepages > > however, demands a NUMAtopology, but as this is one large NUMA > > cell, even with cpu=dedicated or requesting a single numa domain, > > we fail: > > > > compute03, compute03 fails NUMA topology requirements. No host NUMA > > topology while the instance specified one. host_passes > > /usr/lib/python3/dist- > > packages/nova/scheduler/filters/numa_topology_filter.py:119 > > Oh, this is interesting. This would suggest that when NPS is > configured to 1, the host is presented as a UMA system and libvirt > doesn't present topology information for us to parse. That seems odd > and goes against how I though newer versions of libvirt worked. > > What do you see for when you run e.g.: > > $ virsh capabilities | xmllint --xpath > '/capabilities/host/topology' - Also, what version of libvirt are you using? Past investigations [1] led me to believe that libvirt would now always present a NUMA topology for hosts, even if those hosts were in fact UMA. [1] https://github.com/openstack/nova/commit/c619c3b5847de85b21ffcbf750c10421d8b7d193 > > Any idea how to counter this? Setting NPS-2 will create two NUMA > > domains, but also cut our performance way down. > > It's worth noting that by setting NP1 to 1, you're already cutting > your performance. This makes it look like you've got a single NUMA > node but of course, that doesn't change the physical design of the > chip and there are still multiple memory controllers, some of which > will be slower to access to from certain cores. You're simply mixing > best and worst case performance to provide an average. You said you > have two SR-IOV NICs. I assume you're bonding these NICs? If not, you > could set NPS to 2 and then ensure the NICs are in PCI slots that > correspond to different NUMA nodes. You can validate this > configuration using tools like 'lstopo' and 'numactl'. > > Stephen > > > Thanks! > > > > Regards, > > > > Eyle > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eyle.brinkhuis at surf.nl Thu Nov 19 12:56:30 2020 From: eyle.brinkhuis at surf.nl (Eyle Brinkhuis) Date: Thu, 19 Nov 2020 12:56:30 +0000 Subject: NUMATopologyFilter and AMD Epyc Rome In-Reply-To: References: <721C093E-A340-4EA2-A56F-8D704B1343B9@surf.nl> <3635f14885abcb71cf313c1ca81f721920644cc9.camel@redhat.com> Message-ID: Hi Stephen, We run: Compiled against library: libvirt 5.4.0 Using library: libvirt 5.4.0 Using API: QEMU 5.4.0 Running hypervisor: QEMU 4.0.0 ubuntu at compute02:~$ virsh capabilities | xmllint --xpath '/capabilities/host/topology' - XPath set is empty (On a node with NPS-1) compute03:~$ virsh capabilities | xmllint --xpath '/capabilities/host/topology' - 65854792 2383698 27500 0 66014072 2423518 27500 0 (On a node with NPS-2) > It's worth noting that by setting NP1 to 1, you're already cutting your performance. This makes it look like you've got a single NUMA node but of course, that doesn't change the physical design of the chip and there are still multiple memory controllers, some of which will be slower to access to from certain cores. You're simply mixing best and worst case performance to provide an average. You said you have two SR-IOV NICs. I assume you're bonding these NICs? If not, you could set NPS to 2 and then ensure the NICs are in PCI slots that correspond to different NUMA nodes. You can validate this configuration using tools like 'lstopo' and 'numactl'. Our setup is a little different. We don’t use any OVS or SR-IOV. We use FDio’s VPP, with networking-vpp as switch, and use VPP’s RDMA capabilities to haul packets left and right. Our performance tuning sessions on these machines, without an openstack setup (so throughput in VPP) showed that NPS-1 is the best setting for us. We are only using one CX5 by the way, and use both ports (2x100G) in a LACP setup for redundancy. Thanks for your quick reply! Regards, Eyle > On 19 Nov 2020, at 13:31, Stephen Finucane wrote: > > On Thu, 2020-11-19 at 12:25 +0000, Stephen Finucane wrote: >> On Thu, 2020-11-19 at 12:00 +0000, Eyle Brinkhuis wrote: >>> Hi all, >>> >>> We’re running into an issue with deploying our infrastructure to run high throughput, low latency workloads. >>> >>> Background: >>> >>> We run Lenovo SR635 systems with an AMD Epyc 7502P processor. In the BIOS of this system, we are able to define the amount of NUMA cells per socket (called NPS). We can set 1, 2 or 4. As we run a 2x 100Gbit/s Mellanox CX5 in this system as well, we use the preferred-io setting in the BIOS to give preferred io throughput to the Mellanox CX5. >>> To make sure we get as high performance as possible, we set the NPS setting to 1, resulting in a single numa cell with 64 CPU threads available. >>> >>> Next, in Nova (train distribution), we demand huge pages. Hugepages however, demands a NUMAtopology, but as this is one large NUMA cell, even with cpu=dedicated or requesting a single numa domain, we fail: >>> >>> compute03, compute03 fails NUMA topology requirements. No host NUMA topology while the instance specified one. host_passes /usr/lib/python3/dist-packages/nova/scheduler/filters/numa_topology_filter.py:119 >> >> Oh, this is interesting. This would suggest that when NPS is configured to 1, the host is presented as a UMA system and libvirt doesn't present topology information for us to parse. That seems odd and goes against how I though newer versions of libvirt worked. >> >> What do you see for when you run e.g.: >> >> $ virsh capabilities | xmllint --xpath '/capabilities/host/topology' - > > Also, what version of libvirt are you using? Past investigations [1] led me to believe that libvirt would now always present a NUMA topology for hosts, even if those hosts were in fact UMA. > > [1] https://github.com/openstack/nova/commit/c619c3b5847de85b21ffcbf750c10421d8b7d193 > >>> Any idea how to counter this? Setting NPS-2 will create two NUMA domains, but also cut our performance way down. >> >> It's worth noting that by setting NP1 to 1, you're already cutting your performance. This makes it look like you've got a single NUMA node but of course, that doesn't change the physical design of the chip and there are still multiple memory controllers, some of which will be slower to access to from certain cores. You're simply mixing best and worst case performance to provide an average. You said you have two SR-IOV NICs. I assume you're bonding these NICs? If not, you could set NPS to 2 and then ensure the NICs are in PCI slots that correspond to different NUMA nodes. You can validate this configuration using tools like 'lstopo' and 'numactl'. >> >> Stephen >> >>> Thanks! >>> >>> Regards, >>> >>> Eyle -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From smooney at redhat.com Thu Nov 19 12:56:51 2020 From: smooney at redhat.com (Sean Mooney) Date: Thu, 19 Nov 2020 12:56:51 +0000 Subject: NUMATopologyFilter and AMD Epyc Rome In-Reply-To: References: <721C093E-A340-4EA2-A56F-8D704B1343B9@surf.nl> <3635f14885abcb71cf313c1ca81f721920644cc9.camel@redhat.com> Message-ID: <26022927fb68ebdf710263dacf21249d525c6a5d.camel@redhat.com> On Thu, 2020-11-19 at 12:31 +0000, Stephen Finucane wrote: > On Thu, 2020-11-19 at 12:25 +0000, Stephen Finucane wrote: > > On Thu, 2020-11-19 at 12:00 +0000, Eyle Brinkhuis wrote: > > > Hi all, > > > > > > We’re running into an issue with deploying our infrastructure to > > > run high throughput, low latency workloads. > > > > > > Background: > > > > > > We run Lenovo SR635 systems with an AMD Epyc 7502P processor. In > > > the BIOS of this system, we are able to define the amount of NUMA > > > cells per socket (called NPS). We can set 1, 2 or 4. As we run a 2x > > > 100Gbit/s Mellanox CX5 in this system as well, we use the > > > preferred-io setting in the BIOS to give preferred io throughput to > > > the Mellanox CX5. > > > To make sure we get as high performance as possible, we set the NPS > > > setting to 1, resulting in a single numa cell with 64 CPU threads > > > available. from what data i have personllay seen on this topic this will pessimise your perfromance and you should be setting it to 4 if you set it to 1 and place the test applicatio on for example cpus 60-64 you will see a performance reduction in comparisone to cpus 4-8 if you enable 4 numa nodes per socket the 3 that do not have the nic will have more or less teh same performance which should be better then the perfromace when it was on 60-64  but the one with the nic will have better perfromance which may actully exceed the performance you see with the vm/applcaiton running on cores 4-8 the preliminary data our perfomance engineers have seen show that some workloads like small packet netwrok io can see performance improvment of up to 30+% in some workloads (dpdk's testpmd) and 8% improvement in less memory sensitive workloads setting NPS=4 i know mohammed naser looked into this too for vexhost in the past and was seeing similar effect. im not sure if you can share your general finding but did you end up with NPS=4 in the end? > > > > > > Next, in Nova (train distribution), we demand huge pages. Hugepages > > > however, demands a NUMAtopology, but as this is one large NUMA > > > cell, even with cpu=dedicated or requesting a single numa domain, > > > we fail: > > > > > > compute03, compute03 fails NUMA topology requirements. No host NUMA > > > topology while the instance specified one. host_passes > > > /usr/lib/python3/dist- > > > packages/nova/scheduler/filters/numa_topology_filter.py:119 > > > > Oh, this is interesting. This would suggest that when NPS is > > configured to 1, the host is presented as a UMA system and libvirt > > doesn't present topology information for us to parse. That seems odd > > and goes against how I though newer versions of libvirt worked. > > > > What do you see for when you run e.g.: > > > >  $ virsh capabilities | xmllint --xpath > > '/capabilities/host/topology' - > > Also, what version of libvirt are you using? Past investigations [1] > led me to believe that libvirt would now always present a NUMA topology > for hosts, even if those hosts were in fact UMA. > > [1] https://github.com/openstack/nova/commit/c619c3b5847de85b21ffcbf750c10421d8b7d193 libvirt was broken on amd systems with nps=1 due to a workaround implemented for non x86 architures https://bugzilla.redhat.com/show_bug.cgi?id=1860231 that should now by adressed but very recently. > > > > Any idea how to counter this? Setting NPS-2 will create two NUMA > > > domains, but also cut our performance way down. actully that should improve perfromance based on most benchmarks we have seen and work we have been doing with amd on this topic. the data that i have review so far indeicates that the highest memory bandwith and lowest latency occurs when you expose all the numa nodes on the host by setting NPS to the largest value for you given cpu. > > > > It's worth noting that by setting NP1 to 1, you're already cutting > > your performance. This makes it look like you've got a single NUMA > > node but of course, that doesn't change the physical design of the > > chip and there are still multiple memory controllers, some of which > > will be slower to access to from certain cores. You're simply mixing > > best and worst case performance to provide an average. You said you > > have two SR-IOV NICs. I assume you're bonding these NICs? If not, you > > could set NPS to 2 and then ensure the NICs are in PCI slots that > > correspond to different NUMA nodes. You can validate this > > configuration using tools like 'lstopo' and 'numactl'. yep setting it to 1 will just disable the reporting of the real numa toplogy and basically tieing all the memroy contolers in the socket to act as one but that generally increases latency and decreasess perfromance. it also does not provide the information need by the kernel or openstack to optimisze. the main issue we have right now form an openstack point of view is sriov we support numa affintiy but not not socket affintiy or numa distance socket affinity is what you want 80% of the time numa distance is much more complex and is what you actully want but socket affinity is a very good proxy for it. to use sriov with numa guests such as hugepage guests you have to disable numa affinity for sriov devices in if you have hsots with multiple numa nodes per socket today if you want to be able to use all cores. if not all vms will use sriov then you can still use strict/legacy affinity instead of prefered. > > > > Stephen > > > > > Thanks! > > > > > > Regards, > > > > > > Eyle > > > > > > From smooney at redhat.com Thu Nov 19 13:30:21 2020 From: smooney at redhat.com (Sean Mooney) Date: Thu, 19 Nov 2020 13:30:21 +0000 Subject: NUMATopologyFilter and AMD Epyc Rome In-Reply-To: References: <721C093E-A340-4EA2-A56F-8D704B1343B9@surf.nl> <3635f14885abcb71cf313c1ca81f721920644cc9.camel@redhat.com> Message-ID: <7466c091c321e6e18aabf2957e232314fb0b154f.camel@redhat.com> On Thu, 2020-11-19 at 12:56 +0000, Eyle Brinkhuis wrote: > Hi Stephen, > > We run: > Compiled against library: libvirt 5.4.0 > Using library: libvirt 5.4.0 > Using API: QEMU 5.4.0 > Running hypervisor: QEMU 4.0.0 > > ubuntu at compute02:~$ virsh capabilities | xmllint --xpath '/capabilities/host/topology' - > XPath set is empty > (On a node with NPS-1) > > compute03:~$ virsh capabilities | xmllint --xpath '/capabilities/host/topology' - > >       >         >           65854792 >           2383698 >           27500 >           0 >           >             >             >           >           >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >           >         >         >           66014072 >           2423518 >           27500 >           0 >           >             >             >           >           >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >             >           >         >       >     > (On a node with NPS-2) > > > It's worth noting that by setting NP1 to 1, you're already cutting your performance. This makes it look like you've got a single NUMA node but of > > course, that doesn't change the physical design of the chip and there are still multiple memory controllers, some of which will be slower to > > access to from certain cores. You're simply mixing best and worst case performance to provide an average. You said you have two SR-IOV NICs. I > > assume you're bonding these NICs? If not, you could set NPS to 2 and then ensure the NICs are in PCI slots that correspond to different NUMA > > nodes. You can validate this configuration using tools like 'lstopo' and 'numactl'. > Our setup is a little different. We don’t use any OVS or SR-IOV. We use FDio’s VPP, with networking-vpp as switch, and use VPP’s RDMA capabilities > to haul packets left and right. Our performance tuning sessions on these machines, without an openstack setup (so throughput in VPP) showed that > NPS-1 is the best setting for us. We are only using one CX5 by the way, and use both ports (2x100G) in a LACP setup for redundancy. interesting when you set NPS to 4 did you ensure you have 1 PMD per numa node. when using dpdk you should normally have 1 PMD per numa node. the other thing to note is that you cant assume that the nic even if attache to socket 0 will be on numa 0 when you set NPS=4 we havesee it on other numa nodes in some test we have done so if you only have 1 PMD per socket enabeld you woudl want to ensure its on a core in the same numa ndoe as the nic. > > Thanks for your quick reply! > > Regards, > > Eyle > > > On 19 Nov 2020, at 13:31, Stephen Finucane wrote: > > > > On Thu, 2020-11-19 at 12:25 +0000, Stephen Finucane wrote: > > > On Thu, 2020-11-19 at 12:00 +0000, Eyle Brinkhuis wrote: > > > > Hi all, > > > > > > > > We’re running into an issue with deploying our infrastructure to run high throughput, low latency workloads. > > > > > > > > Background: > > > > > > > > We run Lenovo SR635 systems with an AMD Epyc 7502P processor. In the BIOS of this system, we are able to define the amount of NUMA cells per > > > > socket (called NPS). We can set 1, 2 or 4. As we run a 2x 100Gbit/s Mellanox CX5 in this system as well, we use the preferred-io setting in > > > > the BIOS to give preferred io throughput to the Mellanox CX5. > > > > To make sure we get as high performance as possible, we set the NPS setting to 1, resulting in a single numa cell with 64 CPU threads > > > > available. > > > > > > > > Next, in Nova (train distribution), we demand huge pages. Hugepages however, demands a NUMAtopology, but as this is one large NUMA cell, even > > > > with cpu=dedicated or requesting a single numa domain, we fail: > > > > > > > > compute03, compute03 fails NUMA topology requirements. No host NUMA topology while the instance specified one. host_passes > > > > /usr/lib/python3/dist-packages/nova/scheduler/filters/numa_topology_filter.py:119 > > > > > > Oh, this is interesting. This would suggest that when NPS is configured to 1, the host is presented as a UMA system and libvirt doesn't present > > > topology information for us to parse. That seems odd and goes against how I though newer versions of libvirt worked. > > > > > > What do you see for when you run e.g.: > > > > > >         $ virsh capabilities | xmllint --xpath '/capabilities/host/topology' - > > > > Also, what version of libvirt are you using? Past investigations [1] led me to believe that libvirt would now always present a NUMA topology for > > hosts, even if those hosts were in fact UMA. > > > > [1] https://github.com/openstack/nova/commit/c619c3b5847de85b21ffcbf750c10421d8b7d193 > > > > > > Any idea how to counter this? Setting NPS-2 will create two NUMA domains, but also cut our performance way down. > > > > > > It's worth noting that by setting NP1 to 1, you're already cutting your performance. This makes it look like you've got a single NUMA node but > > > of course, that doesn't change the physical design of the chip and there are still multiple memory controllers, some of which will be slower to > > > access to from certain cores. You're simply mixing best and worst case performance to provide an average. You said you have two SR-IOV NICs. I > > > assume you're bonding these NICs? If not, you could set NPS to 2 and then ensure the NICs are in PCI slots that correspond to different NUMA > > > nodes. You can validate this configuration using tools like 'lstopo' and 'numactl'. > > > > > > Stephen > > > > > > > Thanks! > > > > > > > > Regards, > > > > > > > > Eyle > From kgiusti at gmail.com Thu Nov 19 13:32:27 2020 From: kgiusti at gmail.com (Ken Giusti) Date: Thu, 19 Nov 2020 08:32:27 -0500 Subject: [oslo] following or not following the DST changes for our meeting time In-Reply-To: References: Message-ID: On Wed, Nov 18, 2020 at 7:56 AM Moises Guimaraes de Medeiros < moguimar at redhat.com> wrote: > Hi Hervé, > > Historically, Oslo team meeting has been at 1500 UTC, which translates to > 3PM UTC, > I think the discussed proposal in the oslo irc meeting was 1500 UTC with > DST and > 1600 UTC without DST, which translates to 3PM UTC and 4PM UTC accordingly. > > I other words, that means that we should move the slot from 1500 UTC to > 1600 UTC > with the recent time change. > > On Mon, Nov 16, 2020 at 2:51 PM Herve Beraud wrote: > >> Hello Oslofolk, >> >> As discussed during our previous meeting, at each DST change, the agenda >> of some of us conflicting with our Oslo meeting time slot, this thread just >> wants to propose a solution to avoid that. >> >> We could just move our meeting time when DST changes, and then move back >> to this slot once DST is back. >> >> Right now our meeting time is UTC based, we suppose that UTC is required >> because of the OpenStack meeting tooling. >> >> By following that we will get the following time slots: >> >> - meeting time slot when DST start: 5:00pm UTC >> >> - meeting time slot when DST end: 4:00pm UTC >> >> Does it fit well for you? >> >> -- >> Hervé Beraud >> Senior Software Engineer at Red Hat >> irc: hberaud >> https://github.com/4383/ >> https://twitter.com/4383hberaud >> -----BEGIN PGP SIGNATURE----- >> >> wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ >> Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ >> RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP >> F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G >> 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g >> glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw >> m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ >> hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 >> qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y >> F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 >> B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O >> v6rDpkeNksZ9fFSyoY2o >> =ECSj >> -----END PGP SIGNATURE----- >> >> > > -- > > Moisés Guimarães > > Software Engineer > > Red Hat > > > The proposed time slots work for me - no conflicts here. -- Ken Giusti (kgiusti at gmail.com) -------------- next part -------------- An HTML attachment was scrubbed... URL: From aj at suse.com Thu Nov 19 13:51:21 2020 From: aj at suse.com (Andreas Jaeger) Date: Thu, 19 Nov 2020 14:51:21 +0100 Subject: [oslo] following or not following the DST changes for our meeting time In-Reply-To: References: Message-ID: <0b678739-086a-2a6c-7809-3c759bb1145d@suse.com> On 16.11.20 14:50, Herve Beraud wrote: > Hello Oslofolk, > > As discussed during our previous meeting, at each DST change, the agenda > of some of us conflicting with our Oslo meeting time slot, this thread > just wants to propose a solution to avoid that. > > We could just move our meeting time when DST changes, and then move back > to this slot once DST is back. > > Right now our meeting time is UTC based, we suppose that UTC is required > because of the OpenStack meeting tooling. > > By following that we will get the following time slots: > > - meeting time slot when DST start: 5:00pm UTC > > - meeting time slot when DST end: 4:00pm UTC > > Does it fit well for you? Just one comment: Which country are you taking as reference? as an example DST in Europe, US, and Australia are at totally different times... so, best to clarify what you take as reference to avoid confusion - especially for those few weeks when the US has DST but Europe not - leaving the southern hemisphere out of this, Andreas -- Andreas Jaeger aj at suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB From hberaud at redhat.com Thu Nov 19 13:57:21 2020 From: hberaud at redhat.com (Herve Beraud) Date: Thu, 19 Nov 2020 14:57:21 +0100 Subject: [oslo][release] Oslo's Transition To Independent In-Reply-To: <86f35998-1d6e-85b1-5c3b-e25e45cdd37f@nemebean.com> References: <4a9dc3ba-ef77-fdfd-2729-b7cb6357e3ed@nemebean.com> <86f35998-1d6e-85b1-5c3b-e25e45cdd37f@nemebean.com> Message-ID: Le ven. 13 nov. 2020 à 16:29, Ben Nemec a écrit : > > > On 11/13/20 7:05 AM, Herve Beraud wrote: > > Thanks Julia for your response :) > > > > I propose the following migration. > > > > Transitioning to independent [1] model: > > - oslo.i18 > > - oslo.log > > - oslo.reports > > - oslo.upgradecheck > > - oslotest > > - osprofiler > > - stevedore > > - taskflow > > - tooz > > These all sound good to me. Honestly, anything that's not oslo.* > probably should be on an independent release model since they're > explicitly intended for use outside of OpenStack. > > > > > Remaining under the cycle-with-intermediary [2] model: > > - oslo.concurrency > > This doesn't seem particularly tied to a release. Is there a reason it > should stay on the cycle release schedule? > > > - oslo.config > > - oslo.context > > - oslo.db > > - oslo.limit > > - oslo.messaging > > - oslo.middleware > > - oslo.policy > > - oslo.privsep > > - oslo.rootwrap > > Given that rootwrap is essentially in maintenance mode and will > hopefully not be used once we complete the privsep community goal, I > feel like this one could go independent too. > > > - oslo.serialization > > - oslo.service > > - oslo.utils > > - oslo.versionedobjects > > - oslo.vmware > > > > I'll wait a bit before proposing the migration to allow everybody to > > react about the proposed lists. > > > > Let me know if it makes sense for you and don't hesitate to debate on > > the proposed migration. > > The proposed changes lgtm. I think we could move a couple more as > discussed above, but I'm good with it either way. > I wasn't sure about oslo.concurrency and oslo.rootwrap, but I agree with you they could be moved too. I'll propose the transition next week. Thanks to everyone who joined this discussion. > > > > > [1] > https://releases.openstack.org/reference/release_models.html#independent > > [2] > > > https://releases.openstack.org/reference/release_models.html#cycle-with-intermediary > > > > > > Le lun. 9 nov. 2020 à 17:15, Julia Kreger > > a écrit : > > > > Top posting because I'm a horrible person. > > > > Anyway, I think moving oslo to independent makes lots of sense, at > > least to me. The key I think is to have the ability to backport and > > release a patch/revisin/fix release if there is a major issue, but > the > > obligation to backport or even set a foundation to do so is a whole > > other matter. > > > > My overall feeling, for something as stable as the oslo libraries, > > that cycle-with-intermediacy path may just end up being a frustrating > > headache, that is if the team feels confident and actively manages > > their own releases of the various libraries. Also, Under the existing > > model and policy of the release team, they would basically end up > back > > where they started if the libraries failed to release multiple times, > > which may not make sense for stable libraries. > > > > Anyway, just my $0.02. > > > > -Julia > > > > On Fri, Nov 6, 2020 at 2:04 AM Herve Beraud > > wrote: > > > > > > First, thanks for your answer. > > > > > > Le mer. 4 nov. 2020 à 15:50, Ben Nemec > > a écrit : > > >> > > >> > > >> > > >> On 11/4/20 7:31 AM, Herve Beraud wrote: > > >> > Greetings, > > >> > > > >> > Is it time for us to move some parts of Oslo to the > > independent release > > >> > model [1]? > > >> > > > >> > I think we could consider Oslo world is mostly stable enough > > to answer > > >> > yes to the previous question. > > >> > > > >> > However, the goal of this email is to trigger the debat and > > see which > > >> > deliverables could be transitioned to the independent model. > > >> > > > >> > Do we need to expect that major changes will happen within > > Oslo and who > > >> > could warrant to continue to follow cycle-with-intermediary > > model [2]? > > >> > > >> I would hesitate to try to predict the future on what will see > major > > >> changes and what won't. I would prefer to look at this more from > the > > >> perspective of what Oslo libraries are tied to the OpenStack > > version. > > >> For example, I don't think oslo.messaging should be moved to > > >> independent. It's important that RPC has a sane version to > version > > >> upgrade path, and the easiest way to ensure that is to keep it > > on the > > >> regular cycle release schedule. The same goes for other > > libraries too: > > >> oslo.versionedobjects, oslo.policy, oslo.service, oslo.db, > > possibly also > > >> things like oslo.config and oslo.context (I suspect contexts > > need to be > > >> release-specific, but maybe someone from a consuming project can > > weigh > > >> in). Even oslo.serialization could have upgrade impacts if it is > > being > > >> used to serialize internal data in a service. > > > > > > > > > Agreed, the goal here isn't to try to move everything to the > > independent model but more to identify which projects could be > > eligible for this switch. > > > I strongly agree that the previous list of projects that you > > quote should stay binded to openstack cycles and should continue to > > rely on stable branches. > > > These kinds of projects and also openstack's services are > > strongly tied to backends, their version, and available APIs and so > > to openstack's series, so they must remain linked to them. > > > > > >> > > >> That said, many of the others can probably be moved. oslo.i18n > and > > >> oslo.upgradecheck are both pretty stable at this point and not > > really > > >> tied to a specific release. As long as we're responsible with > > any future > > >> changes to them it should be pretty safe to make them > independent. > > > > > > > > > Agreed. > > > > > >> > > >> This does raise a question though: Are the benefits of going > > independent > > >> with the release model sufficient to justify splitting the > release > > >> models of the Oslo projects? I assume the motivation is to avoid > > having > > >> to do as many backports of bug fixes, but if we're mostly doing > this > > >> with low-volume, stable projects does it gain us that much? > > > > > > > > > Yes, you're right, it could help us to reduce our needed > > maintenance and so our Oslo's activity in general. > > > Indeed, about 35 projects are hosted by Oslo and concerning the > > active maintainers the trend isn't on the rise. > > > So reducing the number of stable branches to maintain could > > benefit us, and it could be done by moving projects to an > > independent model. > > > > > >> > > >> > > >> I guess I don't have a strong opinion one way or another on this > > yet, > > >> and would defer to our release liaisons if they want to go one > > way or > > >> other other. Hopefully this provides some things to think about > > though. > > > > > > > > > Yes you provided interesting observations, thanks. > > > It could be interesting to get feedback from other cores. > > > > > >> > > >> -Ben > > >> > > > > > > > > > -- > > > Hervé Beraud > > > Senior Software Engineer at Red Hat > > > irc: hberaud > > > https://github.com/4383/ > > > https://twitter.com/4383hberaud > > > -----BEGIN PGP SIGNATURE----- > > > > > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > > > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > > > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > > > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > > > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > > > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > > > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > > > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > > > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > > > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > > > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > > > v6rDpkeNksZ9fFSyoY2o > > > =ECSj > > > -----END PGP SIGNATURE----- > > > > > > > > > > > -- > > Hervé Beraud > > Senior Software Engineer at Red Hat > > irc: hberaud > > https://github.com/4383/ > > https://twitter.com/4383hberaud > > -----BEGIN PGP SIGNATURE----- > > > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > > v6rDpkeNksZ9fFSyoY2o > > =ECSj > > -----END PGP SIGNATURE----- > > > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From moreira.belmiro.email.lists at gmail.com Thu Nov 19 13:58:20 2020 From: moreira.belmiro.email.lists at gmail.com (Belmiro Moreira) Date: Thu, 19 Nov 2020 14:58:20 +0100 Subject: [ops][rdo-users][TripleO][RDO] novajoin project Message-ID: Hello, at CERN we are deploying FreeIPA and the project "novajoin" is very interesting to enroll OpenStack instances. Novajoin is "a nova vendordata plugin for the OpenStack nova metadata service to manage host instantiation in an IPA server." The project is packaged by RDO, so I believe there are some users around. It would be great to hear your experiences with "novajoin". In my prototype the project is working correctly, but now that I'm going deep I'm finding some issues that I would like to discuss. What is the preferred way to report/discuss issues? There is a launchpad page (https://launchpad.net/novajoin) but not much activity during the last months. Is there someone still working on it? thanks, Belmiro -------------- next part -------------- An HTML attachment was scrubbed... URL: From arxcruz at redhat.com Thu Nov 19 13:59:17 2020 From: arxcruz at redhat.com (Arx Cruz) Date: Thu, 19 Nov 2020 14:59:17 +0100 Subject: [tripleo] Copying tripleo container images to quay.io Message-ID: Hello, I just wrote a tool in go that is right now copying every 2 hours all the containers from rdo registry to quay.io. Right now it's copying all branches: master, victoria, ussuri, train, stein, queens and rocky. You can see the containers in https://quay.io/tripleo{release} for example https://quay.io/tripleomaster The tool basically searches for container build jobs with success status, parse the containers that was built, copy these containers to quay.io and tag it with current-tripleo and the built hash. The code it's based on skopeo, and I did not use it, because there are some other stuff required on quay.io side that requires the use of quay.io api, like create an already public repository, parsing the tripleo container build job, tagging, etc. Also I wanted to play with go :) Right now the code is under review at https://review.rdoproject.org/r/#/c/31133/ and I got it running on our toolbox, and he's an log example (without the --debug flag) time="2020-11-19T12:06:17Z" level=info msg="Copying image centos-binary-horizon:4fad79713786f77292e59fa1c036f588 in tripleoussuri namespace" time="2020-11-19T12:06:18Z" level=info msg="Tagging current-tripleo to sha256:db39e7d43d4c8eec82f61acd4956d7f165b595d515f270f8dabe0c9b009c95f2" "Updated" time="2020-11-19T12:06:19Z" level=info msg="Copying image centos-binary-ceilometer-base:4fad79713786f77292e59fa1c036f588 in tripleoussuri namespace" time="2020-11-19T12:06:20Z" level=info msg="Tagging current-tripleo to sha256:5eee849a9f74d0107cbfd2f456f701be37256ea711079cffcc189d140e8f3176" "Updated" time="2020-11-19T12:06:21Z" level=info msg="Copying image centos-binary-gnocchi-base:4fad79713786f77292e59fa1c036f588 in tripleoussuri namespace" time="2020-11-19T12:06:22Z" level=info msg="Tagging current-tripleo to sha256:5b46ea43d41e56dd81005a234631905a8ad594ef8432ae78542392114956f85e" "Updated" If you want to play around with this, feel free to do so, and any feedback is welcome :) Kind regards, -- Arx Cruz Software Engineer Red Hat EMEA arxcruz at redhat.com @RedHat Red Hat Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From admin at gsic.uva.es Thu Nov 19 14:01:58 2020 From: admin at gsic.uva.es (Cristina Mayo) Date: Thu, 19 Nov 2020 15:01:58 +0100 Subject: [neutron] Floating ips instances not appear in tcpdump Message-ID: <60929F10-026A-47E2-A4AC-C1378351F4E7@getmailspring.com> Hello, I have a multinode Openstack cloud installed on Ubuntu machines following the official guides, without extra settings. I have realised that all the income traffic on my instances with floating ips have the same source ip (controller's node ip address). Could anyone help to understand this behaviour? I would like source ip address remains because I am interested in filter traffic, and it's currently impossible. It seems that my controller node is changing the original ip to the packets. Thanks in advance, Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Thu Nov 19 14:02:08 2020 From: hberaud at redhat.com (Herve Beraud) Date: Thu, 19 Nov 2020 15:02:08 +0100 Subject: [oslo] following or not following the DST changes for our meeting time In-Reply-To: <0b678739-086a-2a6c-7809-3c759bb1145d@suse.com> References: <0b678739-086a-2a6c-7809-3c759bb1145d@suse.com> Message-ID: Good point, I considered the Europe DST, as the origin of the discussion was mostly from European people of the team. Is it fit well for you all? Le jeu. 19 nov. 2020 à 14:54, Andreas Jaeger a écrit : > On 16.11.20 14:50, Herve Beraud wrote: > > Hello Oslofolk, > > > > As discussed during our previous meeting, at each DST change, the agenda > > of some of us conflicting with our Oslo meeting time slot, this thread > > just wants to propose a solution to avoid that. > > > > We could just move our meeting time when DST changes, and then move back > > to this slot once DST is back. > > > > Right now our meeting time is UTC based, we suppose that UTC is required > > because of the OpenStack meeting tooling. > > > > By following that we will get the following time slots: > > > > - meeting time slot when DST start: 5:00pm UTC > > > > - meeting time slot when DST end: 4:00pm UTC > > > > Does it fit well for you? > > Just one comment: Which country are you taking as reference? as an > example DST in Europe, US, and Australia are at totally different times... > > so, best to clarify what you take as reference to avoid confusion - > especially for those few weeks when the US has DST but Europe not - > leaving the southern hemisphere out of this, > > Andreas > -- > Andreas Jaeger aj at suse.com Twitter: jaegerandi > SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg > (HRB 36809, AG Nürnberg) GF: Felix Imendörffer > GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB > > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Thu Nov 19 14:12:14 2020 From: hberaud at redhat.com (Herve Beraud) Date: Thu, 19 Nov 2020 15:12:14 +0100 Subject: [release] Meeting Time Poll In-Reply-To: References: Message-ID: Hello, The majority voted, the new meeting time will be on Thursday at 5:00 pm UTC. This is the most consensual schedule for everyone who voted [1]. This will take effect next week to let everybody organize their time accordingly to the new meeting time. The meeting today will stay planned at 4:00 pm UTC. Thanks for reading. [1] https://doodle.com/poll/7zgvfb8ne54bwhzw Le lun. 26 oct. 2020 à 11:20, Herve Beraud a écrit : > Hello > > We have a few regular attendees of the Release Management meeting who > have conflicts > with the current meeting time. As a result, we would like to find a new > time to hold the meeting. I've created a Doodle poll[1] for everyone to > give their input on times. It's mostly limited to times that reasonably > overlap the working day in the US and Europe since that's where most of > our attendees are located. > > If you attend the Release Management meeting, please fill out the poll so > we can hopefully find a time that works better for everyone. > > Thanks! > > [1] https://doodle.com/poll/7zgvfb8ne54bwhzw > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccamacho at redhat.com Thu Nov 19 14:16:05 2020 From: ccamacho at redhat.com (Carlos Camacho Gonzalez) Date: Thu, 19 Nov 2020 15:16:05 +0100 Subject: [tripleo] Copying tripleo container images to quay.io In-Reply-To: References: Message-ID: Quick question here (maybe I don't have the whole context). Isn't it possible to use tools like skopeo to do this image sync and avoid adding code that will be eventually more complex to maintain? Cheers, Carlos. On Thu, Nov 19, 2020 at 3:05 PM Arx Cruz wrote: > Hello, > > I just wrote a tool in go that is right now copying every 2 hours all the > containers from rdo registry to quay.io. > > Right now it's copying all branches: master, victoria, ussuri, train, > stein, queens and rocky. You can see the containers in > https://quay.io/tripleo{release} for example https://quay.io/tripleomaster > > The tool basically searches for container build jobs with success status, > parse the containers that was built, copy these containers to quay.io and > tag it with current-tripleo and the built hash. > > The code it's based on skopeo, and I did not use it, because there are > some other stuff required on quay.io side that requires the use of quay.io > api, like create an already public repository, parsing the tripleo > container build job, tagging, etc. Also I wanted to play with go :) > > Right now the code is under review at > https://review.rdoproject.org/r/#/c/31133/ and I got it running on our > toolbox, and he's an log example (without the --debug flag) > > time="2020-11-19T12:06:17Z" level=info msg="Copying image > centos-binary-horizon:4fad79713786f77292e59fa1c036f588 in tripleoussuri > namespace" > time="2020-11-19T12:06:18Z" level=info msg="Tagging current-tripleo to > sha256:db39e7d43d4c8eec82f61acd4956d7f165b595d515f270f8dabe0c9b009c95f2" > "Updated" > > time="2020-11-19T12:06:19Z" level=info msg="Copying image > centos-binary-ceilometer-base:4fad79713786f77292e59fa1c036f588 in > tripleoussuri namespace" > time="2020-11-19T12:06:20Z" level=info msg="Tagging current-tripleo to > sha256:5eee849a9f74d0107cbfd2f456f701be37256ea711079cffcc189d140e8f3176" > "Updated" > > time="2020-11-19T12:06:21Z" level=info msg="Copying image > centos-binary-gnocchi-base:4fad79713786f77292e59fa1c036f588 in > tripleoussuri namespace" > time="2020-11-19T12:06:22Z" level=info msg="Tagging current-tripleo to > sha256:5b46ea43d41e56dd81005a234631905a8ad594ef8432ae78542392114956f85e" > "Updated" > > If you want to play around with this, feel free to do so, and any feedback > is welcome :) > > Kind regards, > > > -- > > Arx Cruz > > Software Engineer > > Red Hat EMEA > > arxcruz at redhat.com > @RedHat Red Hat > Red Hat > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccamacho at redhat.com Thu Nov 19 14:25:04 2020 From: ccamacho at redhat.com (Carlos Camacho Gonzalez) Date: Thu, 19 Nov 2020 15:25:04 +0100 Subject: [tripleo] Copying tripleo container images to quay.io In-Reply-To: References: Message-ID: I mean in terms of just adding the bits you are missing? Like the parsing and tagging? On Thu, Nov 19, 2020 at 3:16 PM Carlos Camacho Gonzalez wrote: > Quick question here (maybe I don't have the whole context). > > Isn't it possible to use tools like skopeo to do this image sync and avoid > adding code that will be eventually more complex to maintain? > > Cheers, > Carlos. > > On Thu, Nov 19, 2020 at 3:05 PM Arx Cruz wrote: > >> Hello, >> >> I just wrote a tool in go that is right now copying every 2 hours all the >> containers from rdo registry to quay.io. >> >> Right now it's copying all branches: master, victoria, ussuri, train, >> stein, queens and rocky. You can see the containers in >> https://quay.io/tripleo{release} for example >> https://quay.io/tripleomaster >> >> The tool basically searches for container build jobs with success status, >> parse the containers that was built, copy these containers to quay.io >> and tag it with current-tripleo and the built hash. >> >> The code it's based on skopeo, and I did not use it, because there are >> some other stuff required on quay.io side that requires the use of >> quay.io api, like create an already public repository, parsing the >> tripleo container build job, tagging, etc. Also I wanted to play with go :) >> >> Right now the code is under review at >> https://review.rdoproject.org/r/#/c/31133/ and I got it running on our >> toolbox, and he's an log example (without the --debug flag) >> >> time="2020-11-19T12:06:17Z" level=info msg="Copying image >> centos-binary-horizon:4fad79713786f77292e59fa1c036f588 in tripleoussuri >> namespace" >> time="2020-11-19T12:06:18Z" level=info msg="Tagging current-tripleo to >> sha256:db39e7d43d4c8eec82f61acd4956d7f165b595d515f270f8dabe0c9b009c95f2" >> "Updated" >> >> time="2020-11-19T12:06:19Z" level=info msg="Copying image >> centos-binary-ceilometer-base:4fad79713786f77292e59fa1c036f588 in >> tripleoussuri namespace" >> time="2020-11-19T12:06:20Z" level=info msg="Tagging current-tripleo to >> sha256:5eee849a9f74d0107cbfd2f456f701be37256ea711079cffcc189d140e8f3176" >> "Updated" >> >> time="2020-11-19T12:06:21Z" level=info msg="Copying image >> centos-binary-gnocchi-base:4fad79713786f77292e59fa1c036f588 in >> tripleoussuri namespace" >> time="2020-11-19T12:06:22Z" level=info msg="Tagging current-tripleo to >> sha256:5b46ea43d41e56dd81005a234631905a8ad594ef8432ae78542392114956f85e" >> "Updated" >> >> If you want to play around with this, feel free to do so, and any >> feedback is welcome :) >> >> Kind regards, >> >> >> -- >> >> Arx Cruz >> >> Software Engineer >> >> Red Hat EMEA >> >> arxcruz at redhat.com >> @RedHat Red Hat >> Red Hat >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dms at danplanet.com Thu Nov 19 14:27:54 2020 From: dms at danplanet.com (Dan Smith) Date: Thu, 19 Nov 2020 06:27:54 -0800 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: (=?utf-8?Q?=22Bal=C3=A1zs?= Gibizer"'s message of "Thu, 19 Nov 2020 13:07:58 +0100") References: Message-ID: > I've opened a doc bug to track the minimal config documentation work: > https://bugs.launchpad.net/nova/+bug/1904179 > But I would like to get help from others to start proposing this doc. Yep, I've been kinda thinking about how to arrange it since yesterday. I've only got today and Monday left in the year, so no promises, but I'll try to at least make a start on it. --Dan From dms at danplanet.com Thu Nov 19 14:29:31 2020 From: dms at danplanet.com (Dan Smith) Date: Thu, 19 Nov 2020 06:29:31 -0800 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: <7941321605772116@mail.yandex.ru> (Dmitriy Rabotyagov's message of "Thu, 19 Nov 2020 10:04:21 +0200") References: <7941321605772116@mail.yandex.ru> Message-ID: > I think it's important that Action 1 and Action 2 should be made > before X then (perfectly during W), otherwise futher delaying of the > strick check does not make much sense as it still be kind of urgent > change. Yep, the goal would be to do items 1, 2, and 4 in W and then not merge the hard fail patch until X. Thanks! --Dan From alee at redhat.com Thu Nov 19 14:31:14 2020 From: alee at redhat.com (Ade Lee) Date: Thu, 19 Nov 2020 09:31:14 -0500 Subject: [ops][rdo-users][TripleO][RDO] novajoin project In-Reply-To: References: Message-ID: <7751e3d25f69a0d35bb551571373f0eadbeda9c3.camel@redhat.com> Hi Belmiro, Novajoin is being actively maintained by Red Hat - and has been used primarily as a way to bootstrap controllers and computes in a tripleo deployment to IPA, so as to obtain certificates for TLS-Everywhere. Most recently, though, we've decided to move to an ansible based approach -- https://opendev.org/x/tripleo-ipa. We have deprecated the use of novajoin within the tripleo context accordingly. It sounds, though, like you are using novajoin in the overcloud? In any case, you can create issues on the launchpad page, or contact me on irc (ade_lee, on #tripleo or #openstack-barbican or #freeipa) to discuss issues further. I'd be interested to know what your use case is. Thanks, Ade On Thu, 2020-11-19 at 14:58 +0100, Belmiro Moreira wrote: > Hello, > at CERN we are deploying FreeIPA and the project "novajoin" > is very interesting to enroll OpenStack instances. > Novajoin is "a nova vendordata plugin for the OpenStack nova > metadata service to manage host instantiation in an IPA server." > > The project is packaged by RDO, so I believe there are some users > around. > It would be great to hear your experiences with "novajoin". > > In my prototype the project is working correctly, but now that > I'm going deep I'm finding some issues that I would like to discuss. > > What is the preferred way to report/discuss issues? > There is a launchpad page (https://launchpad.net/novajoin) but not > much > activity during the last months. > Is there someone still working on it? > > thanks, > Belmiro > From whayutin at redhat.com Thu Nov 19 15:19:14 2020 From: whayutin at redhat.com (Wesley Hayutin) Date: Thu, 19 Nov 2020 08:19:14 -0700 Subject: [tripleo] Copying tripleo container images to quay.io In-Reply-To: References: Message-ID: top-post.. Arx has also now posted the log where this sync / copy can be viewed. If you end up hitting an issue when pulling containers from quay, this log would be a good place to poke at. http://38.102.83.131/copy-quay.txt Thanks all and thanks Arx!!! On Thu, Nov 19, 2020 at 7:32 AM Carlos Camacho Gonzalez wrote: > I mean in terms of just adding the bits you are missing? Like the parsing > and tagging? > > On Thu, Nov 19, 2020 at 3:16 PM Carlos Camacho Gonzalez < > ccamacho at redhat.com> wrote: > >> Quick question here (maybe I don't have the whole context). >> >> Isn't it possible to use tools like skopeo to do this image sync and >> avoid adding code that will be eventually more complex to maintain? >> >> Cheers, >> Carlos. >> >> On Thu, Nov 19, 2020 at 3:05 PM Arx Cruz wrote: >> >>> Hello, >>> >>> I just wrote a tool in go that is right now copying every 2 hours all >>> the containers from rdo registry to quay.io. >>> >>> Right now it's copying all branches: master, victoria, ussuri, train, >>> stein, queens and rocky. You can see the containers in >>> https://quay.io/tripleo{release} for example >>> https://quay.io/tripleomaster >>> >>> The tool basically searches for container build jobs with success >>> status, parse the containers that was built, copy these containers to >>> quay.io and tag it with current-tripleo and the built hash. >>> >>> The code it's based on skopeo, and I did not use it, because there are >>> some other stuff required on quay.io side that requires the use of >>> quay.io api, like create an already public repository, parsing the >>> tripleo container build job, tagging, etc. Also I wanted to play with go :) >>> >>> Right now the code is under review at >>> https://review.rdoproject.org/r/#/c/31133/ and I got it running on our >>> toolbox, and he's an log example (without the --debug flag) >>> >>> time="2020-11-19T12:06:17Z" level=info msg="Copying image >>> centos-binary-horizon:4fad79713786f77292e59fa1c036f588 in tripleoussuri >>> namespace" >>> time="2020-11-19T12:06:18Z" level=info msg="Tagging current-tripleo to >>> sha256:db39e7d43d4c8eec82f61acd4956d7f165b595d515f270f8dabe0c9b009c95f2" >>> "Updated" >>> >>> time="2020-11-19T12:06:19Z" level=info msg="Copying image >>> centos-binary-ceilometer-base:4fad79713786f77292e59fa1c036f588 in >>> tripleoussuri namespace" >>> time="2020-11-19T12:06:20Z" level=info msg="Tagging current-tripleo to >>> sha256:5eee849a9f74d0107cbfd2f456f701be37256ea711079cffcc189d140e8f3176" >>> "Updated" >>> >>> time="2020-11-19T12:06:21Z" level=info msg="Copying image >>> centos-binary-gnocchi-base:4fad79713786f77292e59fa1c036f588 in >>> tripleoussuri namespace" >>> time="2020-11-19T12:06:22Z" level=info msg="Tagging current-tripleo to >>> sha256:5b46ea43d41e56dd81005a234631905a8ad594ef8432ae78542392114956f85e" >>> "Updated" >>> >>> If you want to play around with this, feel free to do so, and any >>> feedback is welcome :) >>> >>> Kind regards, >>> >>> >>> -- >>> >>> Arx Cruz >>> >>> Software Engineer >>> >>> Red Hat EMEA >>> >>> arxcruz at redhat.com >>> @RedHat Red Hat >>> Red Hat >>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jungleboyj at gmail.com Thu Nov 19 16:59:36 2020 From: jungleboyj at gmail.com (Jay Bryant) Date: Thu, 19 Nov 2020 10:59:36 -0600 Subject: [manila] Proposing Maari Tamm for python-manilaclient core In-Reply-To: References: Message-ID: <156382f1-20d8-6be2-da71-f60528c1d4fe@gmail.com> On 11/18/2020 3:52 PM, Victoria Martínez de la Cruz wrote: > Hi everyone, > > It's a great pleasure for me to propose Maari Tamm (maaritamm) for the > python-manilaclient core group. > > Maari joined us as an Outreachy intern working on the manila support > for openstackclient in December 2019. She excelled at delivering the > main task, and she went above and beyond by continuing to contribute > with the community even after her internship finished. She > now continues submitting enhancements for the different manila > components and taking on new challenges as they appear. > > Not only that, Maari joined us as mentor for the manila project in > different efforts we have made: the Open Source Day in Grace Hopper > Celebration 2020 and also mentoring for three students from the Boston > University that are currently working with us in manila. > > Maari is a truly valuable member of our team and I believe she will be > a great addition to the python-manilaclient core reviewers group. > > Looking forward to a positive response. > > All the best, > > Victoria Though I am not a Manila Core I think it is really exciting to see an Outreachy Intern continue on with OpenStack to reach core. A great success story!  Congratulations! Jay (jungleboyj) From ekuvaja at redhat.com Thu Nov 19 17:14:04 2020 From: ekuvaja at redhat.com (Erno Kuvaja) Date: Thu, 19 Nov 2020 17:14:04 +0000 Subject: [all][healthcheck] In-Reply-To: References: Message-ID: On Mon, Nov 16, 2020 at 10:21 AM Lajos Katona wrote: > Hi, > > I send this mail out to summarize the discussion around Healthcheck API on > Neutron PTG, and start a discussion how we can make this most valuable to > the operators. > > On the Neutron PTG etherpad this topic is from L114: > https://etherpad.opendev.org/p/neutron-wallaby-ptg . > > Background: oslo_middleware provides /healthcheck API path(see [1]), which > can be used to poll by services like haproxy, and gives a plugin mechanism > to add some more complicated checks, which can be switched on/off from > config. > > The main questions: > > - Some common guidance what to present to the operators (if you check > [2] and [3] in the comments there are really good questions/concerns) > - Perhaps the API SIG has something about healtcheck, just I can't > find it. > - What to present with and without authentication (after checking > again, I am not sure that it is possible to use authentication for the > healthcheck) > - A way forward can be to make it configurable with default to > authenticated, and give the decision to the admin. > - During the discussion the agreement was to separate the frontend > health from the backend health and use direct indicators (like working db > connectivity, and mq connectivity) instead of indirect indicators (like > agents' health). > > Thanks in advance for the feedback. > > [1] > https://docs.openstack.org/oslo.middleware/latest/reference/healthcheck_plugins.html > [2] https://review.opendev.org/731396 > [3] https://review.opendev.org/731554 > > Regards > Lajos Katona (lajoskatona) > > Hi Lajos, Bit of background in case you don't know. The oslo healthcheck middleware is basically a combination of healthcheck middlewares carried within the few projects ages ago bloated with the plugin framework I don't know of anyone ever adopted using. The main point for those middlewares carried by Swift(I think), Glance definitely and possibly some other projects before osloing it was to give a place for load balancers to ping that does not necessarily need to be logged every few seconds nor need to send the excessive amounts of auth calls to keystone. If I recall correctly you can already place it after keystone middleware if you prefer it being authed, I don't know of anyone who does. Main purpose was to provide a way to detect if the service is not responding or by using the disabled by file to bleed the inflight connections for maintenance and drop them off the pool for new requests. I think the original implementations were somewhere around 10-20 lines of code and did just that job pretty reliably. Based on the plugin model, it's indeed very easy to leak information out of that middleware and I think the plugins used need to take that into account by careful design. I'd very much prefer not breaking the current healthcheck and the very well stabilized API of it that has been in use for years just because someone feels like it's a good idea to make leaky plugins for it. Realizing that agent status might not be the right thing to check is a good start, what you really want to have is indication is the API service able to take in new requests or not, not if all permutations of those requests will succeed on the current system status. Now there are ways to chain multiples of these middlewares with different configs (with different endpoints) and it might be worth considering having your plugins with detailed failure conditions on the admin side that is not exposed to the public and just very simple yei/nei on your public endpoint. Good luck and I hope you find the correct balance of detail from the API and usability. Best, Erno "jokke" Kuvaja -------------- next part -------------- An HTML attachment was scrubbed... URL: From StephenM at lsm.org Thu Nov 19 17:31:08 2020 From: StephenM at lsm.org (Stephen Medina) Date: Thu, 19 Nov 2020 17:31:08 +0000 Subject: [neutron] Floating ips instances not appear in tcpdump In-Reply-To: <60929F10-026A-47E2-A4AC-C1378351F4E7@getmailspring.com> References: <60929F10-026A-47E2-A4AC-C1378351F4E7@getmailspring.com> Message-ID: Which official guides did you use to deploy? -Stephen ________________________________ From: Cristina Mayo Sent: Thursday, November 19, 2020 6:01 AM To: openstack-discuss at lists.openstack.org Subject: [neutron] Floating ips instances not appear in tcpdump Hello, I have a multinode Openstack cloud installed on Ubuntu machines following the official guides, without extra settings. I have realised that all the income traffic on my instances with floating ips have the same source ip (controller's node ip address). Could anyone help to understand this behaviour? I would like source ip address remains because I am interested in filter traffic, and it's currently impossible. It seems that my controller node is changing the original ip to the packets. Thanks in advance, Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdobreli at redhat.com Thu Nov 19 18:03:34 2020 From: bdobreli at redhat.com (Bogdan Dobrelya) Date: Thu, 19 Nov 2020 19:03:34 +0100 Subject: [tripleo] Copying tripleo container images to quay.io In-Reply-To: References: Message-ID: <9c11d0d0-0a20-5c9d-7910-d8af30037c9e@redhat.com> Note that skopeo will shortly have the layers diffs [0] based "copy" operations [1],[2],[3]. It also deduplicates things and uses local cache to not repeat redundant data transfers. Would be great if TripleO container registry could start using that super cool feature as early adoption. We could make a build with these patches and try that for the subject tooling for TCIB distribution over quay.io. IIUC, the process is like: * as input we have full layers from the source registry, built with TCIB; * skopeo uses its super powers to redo it on fly into layers diff * either skopeo as well, or maybe even tripleoclient prepare image CLI pushes those optimized layers of the images to the target quay.io registry. * ??? * profit! [0] https://github.com/containers/image/pull/902 [1] https://github.com/containers/image/pull/1084 [2] https://github.com/containers/storage/pull/775 [3] https://github.com/containers/skopeo/pull/1111 On 11/19/20 3:25 PM, Carlos Camacho Gonzalez wrote: > I mean in terms of just adding the bits you are missing? Like the > parsing and tagging? > > On Thu, Nov 19, 2020 at 3:16 PM Carlos Camacho Gonzalez > > wrote: > > Quick question here (maybe I don't have the whole context). > > Isn't it possible to use tools like skopeo to do this image sync and > avoid adding code that will be eventually more complex to maintain? > > Cheers, > Carlos. > > On Thu, Nov 19, 2020 at 3:05 PM Arx Cruz > wrote: > > Hello, > > I just wrote a tool in go that is right now copying every 2 > hours all the containers from rdo registry to quay.io > . > > Right now it's copying all branches: master, victoria, ussuri, > train, stein, queens and rocky. You can see the containers in > https://quay.io/tripleo{release} > for example > https://quay.io/tripleomaster > > The tool basically searches for container build jobs with > success status, parse the containers that was built, copy these > containers to quay.io and tag it with > current-tripleo and the built hash. > > The code it's based on skopeo, and I did not use it, because > there are some other stuff required on quay.io > side that requires the use of quay.io api, like > create an already public repository, parsing the tripleo > container build job, tagging, etc. Also I wanted to play with go :) > > Right now the code is under review at > https://review.rdoproject.org/r/#/c/31133/ and I got it running > on our toolbox, and he's an log example (without the --debug flag) > > time="2020-11-19T12:06:17Z" level=info msg="Copying image > centos-binary-horizon:4fad79713786f77292e59fa1c036f588 in > tripleoussuri namespace" > time="2020-11-19T12:06:18Z" level=info msg="Tagging > current-tripleo to > sha256:db39e7d43d4c8eec82f61acd4956d7f165b595d515f270f8dabe0c9b009c95f2" > "Updated" > > time="2020-11-19T12:06:19Z" level=info msg="Copying image > centos-binary-ceilometer-base:4fad79713786f77292e59fa1c036f588 > in tripleoussuri namespace" > time="2020-11-19T12:06:20Z" level=info msg="Tagging > current-tripleo to > sha256:5eee849a9f74d0107cbfd2f456f701be37256ea711079cffcc189d140e8f3176" > "Updated" > > time="2020-11-19T12:06:21Z" level=info msg="Copying image > centos-binary-gnocchi-base:4fad79713786f77292e59fa1c036f588 in > tripleoussuri namespace" > time="2020-11-19T12:06:22Z" level=info msg="Tagging > current-tripleo to > sha256:5b46ea43d41e56dd81005a234631905a8ad594ef8432ae78542392114956f85e" > "Updated" > > If you want to play around with this, feel free to do so, and > any feedback is welcome :) > > Kind regards, > > > -- > > Arx Cruz > > Software Engineer > > Red Hat EMEA > > arxcruz at redhat.com > > @RedHat Red Hat > Red Hat > > > -- Best regards, Bogdan Dobrelya, Irc #bogdando From smooney at redhat.com Thu Nov 19 18:41:46 2020 From: smooney at redhat.com (Sean Mooney) Date: Thu, 19 Nov 2020 18:41:46 +0000 Subject: [neutron] Floating ips instances not appear in tcpdump In-Reply-To: References: <60929F10-026A-47E2-A4AC-C1378351F4E7@getmailspring.com> Message-ID: <5ac56ebf4bb5b516e691c1be1e2ed697799544ac.camel@redhat.com> On Thu, 2020-11-19 at 17:31 +0000, Stephen Medina wrote: > Which official guides did you use to deploy? assuming its the install guide this woudl result in a linux bridge deployment. in both the linuxbridge and ml2/ovs cases floting ips are implemented using ip tables mascarade dnat rules that is likely why the souce ip is beign rewritten. https://www.rdoproject.org/networking/networking-in-too-much-detail/#network-host-router-mn covers this. that said it rather old so ignore the quantum names it still work the samemore or less unless you are uing ovn in which case its similar but done with openflow. the imporant line is -A quantum-l3-agent-PREROUTING -d 172.24.4.228/32 -j DNAT --to-destination 10.1.0.2 that maps the 172.24.4.228/32 floating ip to 10.1.0.2 fixed ip although i tought that maintained the orginal source ip. the -A quantum-l3-agent-float-snat -s 10.1.0.2/32 -j SNAT --to-source 172.24.4.228 rule is what maps the reply packet form the private fixed ip to the public floating ip. so unless there is a bug when you tcp dump in the guest teh source ip of the recieved packets should be the ip or the orginal server e.g. your laptop. but the dest ip should be the private fixed ip e.g. 10.1.0.2 in this case. if you tcp dump on you laptop the souce ip of the reply should be the floating ip. and the dest ip should be your laptops. > > -Stephen > > ________________________________ > From: Cristina Mayo > Sent: Thursday, November 19, 2020 6:01 AM > To: openstack-discuss at lists.openstack.org  > Subject: [neutron] Floating ips instances not appear in tcpdump > > Hello, > > I have a multinode Openstack cloud installed on Ubuntu machines following the official guides, without extra settings. I have realised that all the > income traffic on my instances with floating ips have the same source ip (controller's node ip address). Could anyone help to understand this > behaviour? I would like source ip address remains because I am interested in filter traffic, and it's currently impossible. It seems that my > controller node is changing the original ip to the packets. > > Thanks in advance, > Regards > From r.m.budnik at gmail.com Wed Nov 18 21:46:59 2020 From: r.m.budnik at gmail.com (Roman Budnyk) Date: Wed, 18 Nov 2020 23:46:59 +0200 Subject: [sdk] issue in update image method In-Reply-To: References: Message-ID: Hello Artem, sorry, looks like I am not following you... By calling .image I am not receiving methods to work with images, there are some stuff like: [image: image.png] so I am not sure about how to use the image layer directly. And also from your explanation I do not understand the reason why update_image_properties() method is not working with the id or name... I tried to pass here not just image instance, but image['id'], and still receiving the error in runtime: TypeError: existing() argument after ** must be a mapping, not str Will be very thankful if you would have a chance to explain this. Regards, Roman ср, 18 лист. 2020 о 22:25 Artem Goncharov пише: > You are absolutely right, it's all matter of what you pass as an image. I > guess you have a problem due to mixing of different sdk layers of objects > (use connection.get_image and pass it in connection.image.xxx). This is not > designed to work this way and may really show weird behavior. > You are advised to use directly conn.image.xxx methods. The so called > cloud layer (conn.get_xxx or self._connection) is designed to be a level > above the "proxy" and designed to give a higher level access. Those are > generally either to wrap multiple different operations in a single function > or normalize cloud differences. And it might return not completely > compatible objects (both are interpretation of the image, but not > exchangeable). If you want to use it this way you should pass image.id > (image['id']) into other functions. > I know this is a bit weird, but there are reasons for that. > > Artem > > On Wed, 18 Nov 2020, 21:08 Roman Budnyk, wrote: > >> Hello Artem, >> >> Thanks for the reply. >> Actually, I am doing nothing special. Calling the method from the client >> instance and passing there image name (or id): >> >> after analyzing sdk code I came to the understanding that the >> update_image_properties method should work as with string representation of >> name (id) of the image or with the instance of the image class (not sure of >> it's name, but it does not matter here, can be received from >> the get_image() method. >> >> Please let me know if I can give you any additional information on this. >> Appreciate your help. >> >> ср, 18 лист. 2020 о 21:06 Artem Goncharov >> пише: >> >>> Hi Roman, >>> >>> Can you please include some code you use to invoke the mentioned >>> function? >>> >>> I assume you might be calling it in the context that we were not >>> expecting. >>> >>> Thanks, >>> Artem >>> >>> ---- >>> typed from mobile, auto-correct typos assumed >>> ---- >>> >>> On Wed, 18 Nov 2020, 19:55 Roman Budnyk, wrote: >>> >>>> Hello dear developers, >>>> >>>> I was trying to update image data by calling method *update_image_properties. >>>> *Each time I was facing the error: TypeError: existing() argument >>>> after ** must be a mapping, not str >>>> >>>> I did small research in the source code and found a strange solution. >>>> Could you please check this place in the code: >>>> class BaseImageProxy, method update_image_properties (path >>>> /openstack/_base_proxy.py): >>>> >>>> >>>> When I changed it to the below - everything works (with name, id or >>>> image instance): >>>> >>>> could you please check on your end, why the construction *if image is >>>> None *is using and how can we execute the code *self._connection.get_image(image) >>>> *if None is passing as the argument. >>>> >>>> Many thanks! >>>> Regards, >>>> Roman >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 158037 bytes Desc: not available URL: From ankelezhang at gmail.com Thu Nov 19 09:35:15 2020 From: ankelezhang at gmail.com (Ankele zhang) Date: Thu, 19 Nov 2020 17:35:15 +0800 Subject: nova novnc timeout Message-ID: Hello~ I have a OpenStack Rocky platform. My nova.cfg has configured "[consoleauth] token_ttl=360000 [workarounds] enable_consoleauth=true", I get the console url and access my VM console in web. the console url invalid after two or one minutes not 360000s. How can I resolve this? Look forward to hearing from you. Ankele! -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.bujack at desy.de Thu Nov 19 17:56:19 2020 From: stefan.bujack at desy.de (Bujack, Stefan) Date: Thu, 19 Nov 2020 18:56:19 +0100 (CET) Subject: [horizon] Error when clicking instance detailed view after upgrading from ussuri to victoria In-Reply-To: <1024527276.24734200.1605725170754.JavaMail.zimbra@desy.de> References: <1024527276.24734200.1605725170754.JavaMail.zimbra@desy.de> Message-ID: <731048615.28086186.1605808579744.JavaMail.zimbra@desy.de> Hello, is not needed anymore. The problem was a nova policy cat policy.yaml |grep -v "^[[:space:]]*#" "os_compute_api:os-extended-server-attributes": "rule:system_admin_api" => cat policy.yaml |grep -v "^[[:space:]]*#" "os_compute_api:os-extended-server-attributes": "" Greets Stefan Bujack ----- Original Message ----- From: "Stefan Bujack" To: "openstack-discuss" Sent: Wednesday, 18 November, 2020 19:46:10 Subject: [horizon] Error when clicking instance detailed view after upgrading from ussuri to victoria Hello, I am a little lost here. Hopefully some of you nice people could help me with this issue please. We had an Openstack Ussuri deployment on Ubuntu 20.04 and upgraded to Victoria Release via cloud_archive repository Now when I click on any instance for a detailed view I get an error 500 with the following message: ==> /var/log/apache2/error.log <== [Wed Nov 18 19:42:37.883040 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] /usr/lib/python3/dist-packages/django/contrib/staticfiles/templatetags/staticfiles.py:24: RemovedInDjango30Warning: {% load staticfiles %} is deprecated in favor of {% load static %}. [Wed Nov 18 19:42:37.883091 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] warnings.warn( [Wed Nov 18 19:42:37.886358 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] ERROR django.request Internal Server Error: /project/instances/25d58259-9d9d-4215-8fb6-521ff9a5befe/ [Wed Nov 18 19:42:37.886400 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] Traceback (most recent call last): [Wed Nov 18 19:42:37.886407 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 829, in _resolve_lookup [Wed Nov 18 19:42:37.886412 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] current = current[bit] [Wed Nov 18 19:42:37.886416 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] TypeError: 'Server' object is not subscriptable [Wed Nov 18 19:42:37.886421 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] [Wed Nov 18 19:42:37.886425 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] During handling of the above exception, another exception occurred: [Wed Nov 18 19:42:37.886430 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] [Wed Nov 18 19:42:37.886456 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] Traceback (most recent call last): [Wed Nov 18 19:42:37.886460 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/openstack_dashboard/api/base.py", line 139, in __getattribute__ [Wed Nov 18 19:42:37.886465 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return object.__getattribute__(self, attr) [Wed Nov 18 19:42:37.886469 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] AttributeError: 'Server' object has no attribute 'OS-EXT-SRV-ATTR:instance_name' [Wed Nov 18 19:42:37.886473 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] [Wed Nov 18 19:42:37.886477 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] During handling of the above exception, another exception occurred: [Wed Nov 18 19:42:37.886482 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] [Wed Nov 18 19:42:37.886486 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] Traceback (most recent call last): [Wed Nov 18 19:42:37.886501 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line 34, in inner [Wed Nov 18 19:42:37.886647 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] response = get_response(request) [Wed Nov 18 19:42:37.886651 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 145, in _get_response [Wed Nov 18 19:42:37.886656 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] response = self.process_exception_by_middleware(e, request) [Wed Nov 18 19:42:37.886661 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 143, in _get_response [Wed Nov 18 19:42:37.886665 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] response = response.render() [Wed Nov 18 19:42:37.886668 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/response.py", line 106, in render [Wed Nov 18 19:42:37.886672 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] self.content = self.rendered_content [Wed Nov 18 19:42:37.886676 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/response.py", line 83, in rendered_content [Wed Nov 18 19:42:37.886680 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] content = template.render(context, self._request) [Wed Nov 18 19:42:37.886684 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/backends/django.py", line 61, in render [Wed Nov 18 19:42:37.886688 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.template.render(context) [Wed Nov 18 19:42:37.886692 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 171, in render [Wed Nov 18 19:42:37.886696 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self._render(context) [Wed Nov 18 19:42:37.886700 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 163, in _render [Wed Nov 18 19:42:37.886704 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.nodelist.render(context) [Wed Nov 18 19:42:37.886708 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.886717 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.886721 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.886725 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.886730 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/loader_tags.py", line 150, in render [Wed Nov 18 19:42:37.886863 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return compiled_parent._render(context) [Wed Nov 18 19:42:37.886871 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 163, in _render [Wed Nov 18 19:42:37.886875 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.nodelist.render(context) [Wed Nov 18 19:42:37.886894 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.886898 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.886902 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.886906 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.886909 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/loader_tags.py", line 62, in render [Wed Nov 18 19:42:37.886913 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] result = block.nodelist.render(context) [Wed Nov 18 19:42:37.886917 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.886945 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.886973 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.886978 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.886982 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/loader_tags.py", line 62, in render [Wed Nov 18 19:42:37.886986 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] result = block.nodelist.render(context) [Wed Nov 18 19:42:37.886991 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.886996 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.887001 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.887006 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.887019 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 987, in render [Wed Nov 18 19:42:37.887093 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] output = self.filter_expression.resolve(context) [Wed Nov 18 19:42:37.887101 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 671, in resolve [Wed Nov 18 19:42:37.887105 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] obj = self.var.resolve(context) [Wed Nov 18 19:42:37.887109 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 796, in resolve [Wed Nov 18 19:42:37.887113 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] value = self._resolve_lookup(context) [Wed Nov 18 19:42:37.887117 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 858, in _resolve_lookup [Wed Nov 18 19:42:37.887121 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] current = current() [Wed Nov 18 19:42:37.887155 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/horizon/tabs/base.py", line 227, in render [Wed Nov 18 19:42:37.887221 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return render_to_string(self.template_name, {"tab_group": self}) [Wed Nov 18 19:42:37.887236 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/loader.py", line 62, in render_to_string [Wed Nov 18 19:42:37.887242 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return template.render(context, request) [Wed Nov 18 19:42:37.887246 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/backends/django.py", line 61, in render [Wed Nov 18 19:42:37.887250 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.template.render(context) [Wed Nov 18 19:42:37.887254 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 171, in render [Wed Nov 18 19:42:37.887258 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self._render(context) [Wed Nov 18 19:42:37.887262 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 163, in _render [Wed Nov 18 19:42:37.887267 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.nodelist.render(context) [Wed Nov 18 19:42:37.887272 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.887276 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.887280 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.887284 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.887288 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/loader_tags.py", line 150, in render [Wed Nov 18 19:42:37.887293 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return compiled_parent._render(context) [Wed Nov 18 19:42:37.887297 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 163, in _render [Wed Nov 18 19:42:37.887382 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.nodelist.render(context) [Wed Nov 18 19:42:37.887395 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.887403 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.887407 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.887411 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.887415 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/defaulttags.py", line 513, in render [Wed Nov 18 19:42:37.887425 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.nodelist.render(context) [Wed Nov 18 19:42:37.887429 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.887434 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.887438 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.887443 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.887448 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/defaulttags.py", line 309, in render [Wed Nov 18 19:42:37.887453 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return nodelist.render(context) [Wed Nov 18 19:42:37.887458 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.887462 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.887467 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.887472 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.887478 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/defaulttags.py", line 209, in render [Wed Nov 18 19:42:37.887483 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] nodelist.append(node.render_annotated(context)) [Wed Nov 18 19:42:37.887488 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.887493 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.887498 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 987, in render [Wed Nov 18 19:42:37.887503 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] output = self.filter_expression.resolve(context) [Wed Nov 18 19:42:37.887587 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 671, in resolve [Wed Nov 18 19:42:37.887594 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] obj = self.var.resolve(context) [Wed Nov 18 19:42:37.887598 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 796, in resolve [Wed Nov 18 19:42:37.887602 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] value = self._resolve_lookup(context) [Wed Nov 18 19:42:37.887606 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 858, in _resolve_lookup [Wed Nov 18 19:42:37.887610 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] current = current() [Wed Nov 18 19:42:37.887614 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/horizon/tabs/base.py", line 372, in render [Wed Nov 18 19:42:37.887619 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return render_to_string(self.get_template_name(self.request), context) [Wed Nov 18 19:42:37.887634 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/loader.py", line 62, in render_to_string [Wed Nov 18 19:42:37.887638 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return template.render(context, request) [Wed Nov 18 19:42:37.887642 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/backends/django.py", line 61, in render [Wed Nov 18 19:42:37.887652 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.template.render(context) [Wed Nov 18 19:42:37.887657 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 171, in render [Wed Nov 18 19:42:37.887661 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self._render(context) [Wed Nov 18 19:42:37.887665 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 163, in _render [Wed Nov 18 19:42:37.887669 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.nodelist.render(context) [Wed Nov 18 19:42:37.887673 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.887678 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.887682 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.887686 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.887691 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/defaulttags.py", line 302, in render [Wed Nov 18 19:42:37.887696 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] match = condition.eval(context) [Wed Nov 18 19:42:37.887707 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/defaulttags.py", line 876, in eval [Wed Nov 18 19:42:37.887711 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.value.resolve(context, ignore_failures=True) [Wed Nov 18 19:42:37.887729 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 671, in resolve [Wed Nov 18 19:42:37.887734 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] obj = self.var.resolve(context) [Wed Nov 18 19:42:37.887739 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 796, in resolve [Wed Nov 18 19:42:37.887744 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] value = self._resolve_lookup(context) [Wed Nov 18 19:42:37.887748 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 837, in _resolve_lookup [Wed Nov 18 19:42:37.887753 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] current = getattr(current, bit) [Wed Nov 18 19:42:37.887758 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/openstack_dashboard/api/base.py", line 139, in __getattribute__ [Wed Nov 18 19:42:37.887763 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return object.__getattribute__(self, attr) [Wed Nov 18 19:42:37.887767 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/openstack_dashboard/api/_nova.py", line 88, in has_extended_attrs [Wed Nov 18 19:42:37.887772 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return any(getattr(self, attr) for attr in [ [Wed Nov 18 19:42:37.887777 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/openstack_dashboard/api/_nova.py", line 88, in [Wed Nov 18 19:42:37.887782 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return any(getattr(self, attr) for attr in [ [Wed Nov 18 19:42:37.887786 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/openstack_dashboard/api/base.py", line 144, in __getattribute__ [Wed Nov 18 19:42:37.887791 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return getattr(self._apiresource, attr) [Wed Nov 18 19:42:37.887795 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/novaclient/base.py", line 176, in __getattr__ [Wed Nov 18 19:42:37.887800 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] raise AttributeError(k) [Wed Nov 18 19:42:37.887805 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] AttributeError: OS-EXT-SRV-ATTR:instance_name Thanks in advance, Stefan Bujack From skaplons at redhat.com Thu Nov 19 20:58:36 2020 From: skaplons at redhat.com (Slawek Kaplonski) Date: Thu, 19 Nov 2020 21:58:36 +0100 Subject: [neutron] Drivers meeting 20.11.2020 - cancelled Message-ID: <20201119205836.ghi3m4dtvd3cip3o@p1.localdomain> Hi, As there is no any new RFE to discuss, lets cancel this week's meeting. Please instead spent some time on reviewing some opened specs to approved RFEs [1]. Especially: * https://review.opendev.org/#/c/729532/ * https://review.opendev.org/#/c/739549/ * https://review.opendev.org/#/c/728628/ Have a great weekend and see You all online :) [1] https://review.opendev.org/#/q/project:openstack/neutron-specs++status:open -- Slawek Kaplonski Principal Software Engineer Red Hat From melwittt at gmail.com Thu Nov 19 21:25:36 2020 From: melwittt at gmail.com (melanie witt) Date: Thu, 19 Nov 2020 13:25:36 -0800 Subject: nova novnc timeout In-Reply-To: References: Message-ID: <5f1f6998-48ef-e065-bd81-9b92ccdcf4f3@gmail.com> On 11/19/20 01:35, Ankele zhang wrote: > Hello~ >     I have a OpenStack Rocky platform. My nova.cfg has configured > "[consoleauth] token_ttl=360000 [workarounds] enable_consoleauth=true", > I get the console url and access my VM console in web. the console url > invalid after two or one minutes not 360000s. >     How can I resolve this? >     Look forward to hearing from you. Hi Ankele, I'm sure you have already read this but for reference, this is the blurb in the release notes around the console proxy changes [1]. Note that the [workarounds]enable_consoleauth option has been removed in the Train release, so to avoid interruptions in consoles during an upgrade to Train, you must ensure your deployment has fully migrated to the new per-cell console proxy model in Rocky or Stein. In Rocky, console token auths are stored in the cell database(s) (new way) and if [workarounds]enable_consoleauth=true on the nova-api nodes, they are additionally stored in the nova-consoleauth service (old way). Then, on the console proxy side, if [workarounds]enable_consoleauth=true on the nova-novncproxy nodes, the proxy will first try to validate the token in the nova-consoleauth service (old way) and if that's not successful, it will fall back to contacting the cell database to validate the token (new way). In order for it to succeed at validating the token in the cell database, the nova-novncproxy needs to be deployed per cell and have access to the cell database [database]connection. If you need to use nova-consoleauth to transition to the database-backend model, you must set [workarounds]enable_consoleauth=true on both the nova-novncproxy nodes (for token validation) and the nova-api nodes (for token auth storage in the old way). The [consoleauth]token_ttl option needs to be set to the value you desire on both the nova-consoleauth nodes (old way) and nova-compute nodes (new way). So, I suspect the issue is you need to set the aforementioned config options on nodes where you don't yet have them set. To transition to the new way without console interruption, you will need to (1) deploy nova-novncproxy services to each of your cells and make sure they have [database]connection set to the corresponding cell database, (2) wait until all token auths generated before Rocky are expired, (3) set [workarounds]enable_consoleauth=false on nova-novncproxy and nova-api nodes, (4) remove the nova-consoleauth service from your deployment. Hope this helps, -melanie [1] https://docs.openstack.org/releasenotes/nova/rocky.html#relnotes-18-0-0-stable-rocky-upgrade-notes From kennelson11 at gmail.com Thu Nov 19 22:09:34 2020 From: kennelson11 at gmail.com (Kendall Nelson) Date: Thu, 19 Nov 2020 14:09:34 -0800 Subject: [all][diversity] IRC Channel Renames Message-ID: Hello! So now that the OpenStack Foundation is now the Open Infrastructure Foundation, I think it time to take a look at some of the IRC channels we use. There are a few that come to mind that are used by the larger Foundation community- not just OpenStack anymore- that should probably be renamed[0]. Below is a list of the channels that come to mind and proposed new channel names. Please add to the list or suggest alternative names if you hate what I've come up with. My goal is to process these renames by the end of the year. - #openstack-ptg -> #oif-ptg - #openstack-forum -> #oif-forum - #openstack-diversity -> #oif-diversity - #openstack-board -> #oif-board - #openstack-foundation -> #oif-foundation Look forward to everyone's thoughts! -Kendall (diablo_rojo) [0] https://docs.opendev.org/opendev/system-config/latest/irc.html#renaming-an-irc-channel -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Thu Nov 19 22:37:19 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 19 Nov 2020 22:37:19 +0000 Subject: [all][diversity] IRC Channel Renames In-Reply-To: References: Message-ID: <20201119223719.vhit7ipanumckwvu@yuggoth.org> On 2020-11-19 14:09:34 -0800 (-0800), Kendall Nelson wrote: > Below is a list of the channels that come to mind and proposed new > channel names. Please add to the list or suggest alternative names > if you hate what I've come up with. My goal is to process these > renames by the end of the year. > > - #openstack-ptg -> #oif-ptg > - #openstack-forum -> #oif-forum > - #openstack-diversity -> #oif-diversity > - #openstack-board -> #oif-board > - #openstack-foundation -> #oif-foundation I might instead suggest moving the last one as so: - #openstack-foundation -> #oif And there's this recent addition, not sure if it needs to stick around, but... - #openinfra-summit -> #oif-summit Also it feels sort of weird to be talking about this on the openstack-discuss ML instead of the foundation ML, but I guess it can't hurt to solicit ideas here first before starting it up there too. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From amy at demarco.com Thu Nov 19 22:42:19 2020 From: amy at demarco.com (Amy Marrich) Date: Thu, 19 Nov 2020 16:42:19 -0600 Subject: [all][diversity] IRC Channel Renames In-Reply-To: <20201119223719.vhit7ipanumckwvu@yuggoth.org> References: <20201119223719.vhit7ipanumckwvu@yuggoth.org> Message-ID: That makes sense plus Jeremy's suggestions. Amy On Thu, Nov 19, 2020 at 4:40 PM Jeremy Stanley wrote: > On 2020-11-19 14:09:34 -0800 (-0800), Kendall Nelson wrote: > > Below is a list of the channels that come to mind and proposed new > > channel names. Please add to the list or suggest alternative names > > if you hate what I've come up with. My goal is to process these > > renames by the end of the year. > > > > - #openstack-ptg -> #oif-ptg > > - #openstack-forum -> #oif-forum > > - #openstack-diversity -> #oif-diversity > > - #openstack-board -> #oif-board > > - #openstack-foundation -> #oif-foundation > > I might instead suggest moving the last one as so: > > - #openstack-foundation -> #oif > > And there's this recent addition, not sure if it needs to stick > around, but... > > - #openinfra-summit -> #oif-summit > > Also it feels sort of weird to be talking about this on the > openstack-discuss ML instead of the foundation ML, but I guess it > can't hurt to solicit ideas here first before starting it up there > too. > -- > Jeremy Stanley > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennelson11 at gmail.com Thu Nov 19 23:53:09 2020 From: kennelson11 at gmail.com (Kendall Nelson) Date: Thu, 19 Nov 2020 15:53:09 -0800 Subject: [all][diversity] IRC Channel Renames In-Reply-To: References: <20201119223719.vhit7ipanumckwvu@yuggoth.org> Message-ID: On Thu, Nov 19, 2020, 2:42 PM Amy Marrich wrote: > That makes sense plus Jeremy's suggestions. > > Amy > > On Thu, Nov 19, 2020 at 4:40 PM Jeremy Stanley wrote: > >> On 2020-11-19 14:09:34 -0800 (-0800), Kendall Nelson wrote: >> > Below is a list of the channels that come to mind and proposed new >> > channel names. Please add to the list or suggest alternative names >> > if you hate what I've come up with. My goal is to process these >> > renames by the end of the year. >> > >> > - #openstack-ptg -> #oif-ptg >> > - #openstack-forum -> #oif-forum >> > - #openstack-diversity -> #oif-diversity >> > - #openstack-board -> #oif-board >> > - #openstack-foundation -> #oif-foundation >> >> I might instead suggest moving the last one as so: >> >> - #openstack-foundation -> #oif >> >> And there's this recent addition, not sure if it needs to stick >> around, but... >> >> - #openinfra-summit -> #oif-summit >> > I'm good with both of these! >> Also it feels sort of weird to be talking about this on the >> openstack-discuss ML instead of the foundation ML, but I guess it >> can't hurt to solicit ideas here first before starting it up there >> too. >> > Yeah I was planning to post there too once I had some feedback here, but I can post it there sooner than later too. -- >> Jeremy Stanley >> > -Kendall (diablo_rojo) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpena at redhat.com Fri Nov 20 09:46:56 2020 From: jpena at redhat.com (Javier Pena) Date: Fri, 20 Nov 2020 04:46:56 -0500 (EST) Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: Message-ID: <519018307.59148790.1605865616072.JavaMail.zimbra@redhat.com> > > There was a long discussion on #openstack-nova today[3] around this > > topic. So you can find more detailed reasoning there[3]. > > I just had a long voice chat with Ollie about this, trying to understand > some of the challenges that still exist with some of the things we've > discussed and the proposed forward steps. > > There are lots of things to clarify, I think, and we could honestly > probably use a wider voice chat among the people that need to work on > this. However, I'll try here. > > First off, I want to address the "do it like devstack" recommendation, > and the subsequent suggestion of standardizing on something like a > "nova-db.conf" file arrangement to keep the db credentials in one > place. As Ollie has pointed out, devstack doesn't support all the > various deployment arrangements (such as "one metadata api per cell") > and thus doesn't have a prescription for how to arrange the config files > in those scenarios. Specifically, an all-in-one deployment that includes > multiple API services with different configs would currently have to hack > around the hardcoded nova.conf file with the environment variable that > allows them to specify a directory other than /etc/nova.conf. Devstack > doesn't have to do this because it doesn't support that arrangement of > services, but if it did, it would have to. > > So, I wanted to clarify something that came out of the IRC discussion, > which is "do it like devstack". When we say that, or at least when *I* > said it, we meant "have different config files for each service so that > you can get the config elements appropriate for each service set > correctly." That doesn't mean "nova-compute should point to > /etc/nova/nova-cpu.conf because that's what devstack does". Especially > in a containerized setup, I would expect everything to use > /etc/nova/nova.conf, since those are namespaced per-service because of > the containerization. Further, just because devstack doesn't run a > metadata per cell (or any other such optional arrangement), obviously > that doesn't mean you can't. > > That leads me to the first action item I think we need: > > ACTION 1: Make the wsgi app able to use something other than nova.conf > > All of our other services support a --config-file flag, and I don't see > why we wouldn't allow this if it's necessary for deployments. In the > pure API arrangement, it shouldn't really be necessary to change this, > but clearly you may need to have multiple API workers with different > configs, as is the case with metadata-per-cell, or even potentially some > admin-focused private API endpoint. If it makes it easier for deployment > tools to start the API workers with a specific config file, we should > let them do that. You can already work around that hard-coded filename > by setting OS_NOVA_CONFIG_DIR to something other than /etc/nova, but we > shouldn't require them to create directories just to have separate > configs. > > The next item is related: > > ACTION 2: We need to document a minimal viable config for each service > > Ollie points out that, obviously, handing the deployer a config > reference with 1.21 bajillion config options does not clearly indicate > which services need which thing, and especially, which things are > _not_allowed_ to be set for a service (such as db credentials on the > compute). We can't feasibly audit every config option we have, but it > would be very helpful to have a reference that shows what a completely > minimal configuration for each service looks like. We could do that by > tagging services per config options (which I suggested earlier, and > would still be good) but I think maybe a standalone document would be > easier for people to follow. > > Now, on to the question about the hard-fail patch for compute: > > https://review.opendev.org/#/c/762176/ > > The Nova devs have wanted people to _not_ have db credentials in the > config file that nova-compute can see for a "Very Long Time." We have > even made some assumptions in the code that rely on these credentials > being not set on the compute, which is at least partially why we're > having this conversation (again) now. > > Despite the fact that nobody *should* be setting these credentials in > their config file, we know that at in least some circumstances, they > are. TripleO is setting them (always I think?) because puppet-nova does > that. OSA has said that they're setting them somewhat incidentally when > they do all-in-one deployments. The latter is unlikely to affect any > real deployments, but the former definitely _will_, and anyone else that > isn't present in this discussion may be including credentials > unnecessarily, which we will break when we merge that patch. Thus, I > think that, even though it feels long overdue for devs, the most prudent > and cautious approach will be to: > > ACTION 3: Not merge that hard fail until X > > We have the warning, we have the reno. We expect that the deployment > tools will be working to eliminate the credentials for the compute > config, but merging that will make it an emergency for them. We've > waited years at this point, we can wait one more cycle for safety. As > Ollie pointed out, we've not been super clear about messaging this, > despite it being a well-worn assumption amongst the developers for a > long time. > > To aid in smoking out any of the jobs or configs that deployment tools > may still have which will break when we merge that patch, we should also > consider: > > ACTION 4: A workaround flag to opt-in to the strict checking > > Basically, this would be a one or two-cycle workaround, which when > enabled, would opt-in to the (above) behavior of causing compute to fail > on startup if db credentials are present. This would allow the > deployment tool maintainers, as well as people responsible for CI jobs > to smoke test the new behavior early, before we merge it and cause an > emergency for them. We can set this as on by default in our devstack > jobs to signal that it is good with the new behavior, and also encourage > the other deployment projects to set it as well once they're generating > clean configs for their nova-computes. Once we merge the patch to > actually fail all the time, we can remove this workaround config, > according to the original intent of the workarounds group, that those > flags are short-lived. > > We could do this by altering gibi's patch to only fail if the workaround > is enabled, and then follow up in X by removing the workaround check. > > So, I know that was a lot of words, but I think if we can agree to the > above four items, we'll have a path forward that doesn't overly burden > any one specific group while still allowing us to chart a path to > getting where we want to be. > > I think we need acks from a bunch of groups, probably at least: > > - Nova (gibi, stephenfin) > - TripleO (owalsh) > - Debian (zigo) > - Kolla (yoctozepto) > - OSA (noonedeadpunk) > - rdo-ci (jpena) > - puppet-nova (tkajinam) > > Are people okay with these action items? > Hi Dan, Thanks for the detailed proposal. It looks good to me. Echoing Takashi's concerns, it would be great if action 2 could also include generating some separate oslo-config-generator configuration files. That would help distributions generate different nova-*.conf files, and then deployment projects could follow. Regards, Javier > --Dan > > From balazs.gibizer at est.tech Fri Nov 20 09:48:05 2020 From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer) Date: Fri, 20 Nov 2020 10:48:05 +0100 Subject: [nova] Wallaby spec review day, round 2 Message-ID: <5W93KQ.GCR1SLF8GVA83@est.tech> Hi, We had a successful spec review day on Tuesday. Most of the open specs has got reviewer attention. We will do another coordinated spec review round on 1st of December. Cheers, gibi From moreira.belmiro.email.lists at gmail.com Fri Nov 20 10:14:41 2020 From: moreira.belmiro.email.lists at gmail.com (Belmiro Moreira) Date: Fri, 20 Nov 2020 11:14:41 +0100 Subject: [ops][rdo-users][TripleO][RDO] novajoin project In-Reply-To: <7751e3d25f69a0d35bb551571373f0eadbeda9c3.camel@redhat.com> References: <7751e3d25f69a0d35bb551571373f0eadbeda9c3.camel@redhat.com> Message-ID: Hi Ade, thanks for the information and contacts. regards, Belmiro On Thu, Nov 19, 2020 at 3:31 PM Ade Lee wrote: > Hi Belmiro, > > Novajoin is being actively maintained by Red Hat - and has been used > primarily as a way to bootstrap controllers and computes in a tripleo > deployment to IPA, so as to obtain certificates for TLS-Everywhere. > > Most recently, though, we've decided to move to an ansible based > approach -- https://opendev.org/x/tripleo-ipa. We have deprecated the > use of novajoin within the tripleo context accordingly. > > It sounds, though, like you are using novajoin in the overcloud? > > In any case, you can create issues on the launchpad page, or contact me > on irc (ade_lee, on #tripleo or #openstack-barbican or #freeipa) to > discuss issues further. I'd be interested to know what your use case > is. > > Thanks, > Ade > > > > > On Thu, 2020-11-19 at 14:58 +0100, Belmiro Moreira wrote: > > Hello, > > at CERN we are deploying FreeIPA and the project "novajoin" > > is very interesting to enroll OpenStack instances. > > Novajoin is "a nova vendordata plugin for the OpenStack nova > > metadata service to manage host instantiation in an IPA server." > > > > The project is packaged by RDO, so I believe there are some users > > around. > > It would be great to hear your experiences with "novajoin". > > > > In my prototype the project is working correctly, but now that > > I'm going deep I'm finding some issues that I would like to discuss. > > > > What is the preferred way to report/discuss issues? > > There is a launchpad page (https://launchpad.net/novajoin) but not > > much > > activity during the last months. > > Is there someone still working on it? > > > > thanks, > > Belmiro > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From admin at gsic.uva.es Fri Nov 20 10:41:19 2020 From: admin at gsic.uva.es (Cristina Mayo) Date: Fri, 20 Nov 2020 11:41:19 +0100 Subject: [neutron] Floating ips instances not appear in tcpdump In-Reply-To: <5ac56ebf4bb5b516e691c1be1e2ed697799544ac.camel@redhat.com> References: <5ac56ebf4bb5b516e691c1be1e2ed697799544ac.camel@redhat.com> Message-ID: <1B1F2725-083F-4138-B760-1865E91E9D24@getmailspring.com> I'm using installation guides with the self service network option (that includes ML2 plugin and linux bridge agent): https://docs.openstack.org/neutron/train/install/install-ubuntu.html (https://link.getmailspring.com/link/1B1F2725-083F-4138-B760-1865E91E9D24 at getmailspring.com/0?redirect=https%3A%2F%2Fdocs.openstack.org%2Fneutron%2Ftrain%2Finstall%2Finstall-ubuntu.html&recipient=b3BlbnN0YWNrLWRpc2N1c3NAbGlzdHMub3BlbnN0YWNrLm9yZw%3D%3D) What I mean is, for example, if I have an apache server running on an instance with a public ip address (floating ip). When I access to that apache server from whatever external network and I capture the traffic on the instance, all packages come from the same IP. I supposed that the controller node is retransmitting the packages and putting its ip address on them. I capture some packets with tcpdump in this openstack instance with a public ip (floating_ip), for example: 172.24.4.228/32 (https://link.getmailspring.com/link/1B1F2725-083F-4138-B760-1865E91E9D24 at getmailspring.com/1?redirect=172.24.4.228%2F32&recipient=b3BlbnN0YWNrLWRpc2N1c3NAbGlzdHMub3BlbnN0YWNrLm9yZw%3D%3D) and I have a controller node with a public IP, for example 172.24.4.100/32, (https://link.getmailspring.com/link/1B1F2725-083F-4138-B760-1865E91E9D24 at getmailspring.com/2?redirect=172.24.4.228%2F32&recipient=b3BlbnN0YWNrLWRpc2N1c3NAbGlzdHMub3BlbnN0YWNrLm9yZw%3D%3D) the traces of traffic are something like this, but they should have others external sources IPs: # tcpdump tcp and port 443 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ens7, link-type EN10MB (Ethernet), capture size 262144 bytes 13:21:17.272668 IP 172.24.4.100 (https://link.getmailspring.com/link/1B1F2725-083F-4138-B760-1865E91E9D24 at getmailspring.com/3?redirect=172.24.4.228%2F32&recipient=b3BlbnN0YWNrLWRpc2N1c3NAbGlzdHMub3BlbnN0YWNrLm9yZw%3D%3D): (https://link.getmailspring.com/link/1B1F2725-083F-4138-B760-1865E91E9D24 at getmailspring.com/4?redirect=172.24.4.228%2F32&recipient=b3BlbnN0YWNrLWRpc2N1c3NAbGlzdHMub3BlbnN0YWNrLm9yZw%3D%3D)49718 (https://link.getmailspring.com/link/1B1F2725-083F-4138-B760-1865E91E9D24 at getmailspring.com/5?redirect=hermes.gsic.uva.es.49718&recipient=b3BlbnN0YWNrLWRpc2N1c3NAbGlzdHMub3BlbnN0YWNrLm9yZw%3D%3D) > 172.24.4.228.https: Flags [S], seq 3072401769, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 911923475 ecr 0,sackOK,eol], length 0 13:21:17.272787 IP 172.24.4.228.https > 172.24.4.100 (https://link.getmailspring.com/link/1B1F2725-083F-4138-B760-1865E91E9D24 at getmailspring.com/6?redirect=172.24.4.228%2F32&recipient=b3BlbnN0YWNrLWRpc2N1c3NAbGlzdHMub3BlbnN0YWNrLm9yZw%3D%3D): (https://link.getmailspring.com/link/1B1F2725-083F-4138-B760-1865E91E9D24 at getmailspring.com/7?redirect=172.24.4.228%2F32&recipient=b3BlbnN0YWNrLWRpc2N1c3NAbGlzdHMub3BlbnN0YWNrLm9yZw%3D%3D)49718: (https://link.getmailspring.com/link/1B1F2725-083F-4138-B760-1865E91E9D24 at getmailspring.com/8?redirect=hermes.gsic.uva.es.49718%3A&recipient=b3BlbnN0YWNrLWRpc2N1c3NAbGlzdHMub3BlbnN0YWNrLm9yZw%3D%3D) Flags [S.], seq 678353364, ack 3072401770, win 64308, options [mss 1410,sackOK,TS val 246556960 ecr 911923475,nop,wscale 7], length 0 13:21:17.273556 IP 172.24.4.10 (https://link.getmailspring.com/link/1B1F2725-083F-4138-B760-1865E91E9D24 at getmailspring.com/9?redirect=172.24.4.228%2F32&recipient=b3BlbnN0YWNrLWRpc2N1c3NAbGlzdHMub3BlbnN0YWNrLm9yZw%3D%3D)0: (https://link.getmailspring.com/link/1B1F2725-083F-4138-B760-1865E91E9D24 at getmailspring.com/10?redirect=172.24.4.228%2F32&recipient=b3BlbnN0YWNrLWRpc2N1c3NAbGlzdHMub3BlbnN0YWNrLm9yZw%3D%3D)49718 (https://link.getmailspring.com/link/1B1F2725-083F-4138-B760-1865E91E9D24 at getmailspring.com/11?redirect=hermes.gsic.uva.es.49718&recipient=b3BlbnN0YWNrLWRpc2N1c3NAbGlzdHMub3BlbnN0YWNrLm9yZw%3D%3D) > 172.24.4.228.https: Flags [.], ack 1, win 2053, options [nop,nop,TS val 911923476 ecr 246556960], length 0 So, I can't filter the traffic (in this case http/https) received in the openstack instance because all have the same IP address. The only way that I can see the original ips are capturing packages on the controller node. I don't have a lot experienced and I'd like to understand it. I hope I have explained better than before. -------------- next part -------------- An HTML attachment was scrubbed... URL: From amotoki at gmail.com Fri Nov 20 12:48:41 2020 From: amotoki at gmail.com (Akihiro Motoki) Date: Fri, 20 Nov 2020 21:48:41 +0900 Subject: [horizon] Error when clicking instance detailed view after upgrading from ussuri to victoria In-Reply-To: <731048615.28086186.1605808579744.JavaMail.zimbra@desy.de> References: <1024527276.24734200.1605725170754.JavaMail.zimbra@desy.de> <731048615.28086186.1605808579744.JavaMail.zimbra@desy.de> Message-ID: Hi Stefan, It is a bug of victoria horizon. I filed it to Launchpad and marked it as Critical. https://bugs.launchpad.net/horizon/+bug/1905024 A fix was just proposed in https://review.opendev.org/763551. Once it is merged we will backport it to stable/victoria quickly. Your workaround to relax the nova policy works to avoid this attribute error but it potentially expose system information to regular users. I would suggest not to do so. Akihiro Motoki (irc: amotoki) On Fri, Nov 20, 2020 at 3:58 AM Bujack, Stefan wrote: > > Hello, > > is not needed anymore. The problem was a nova policy > > cat policy.yaml |grep -v "^[[:space:]]*#" > "os_compute_api:os-extended-server-attributes": "rule:system_admin_api" > => > cat policy.yaml |grep -v "^[[:space:]]*#" > "os_compute_api:os-extended-server-attributes": "" > > Greets Stefan Bujack > > ----- Original Message ----- > From: "Stefan Bujack" > To: "openstack-discuss" > Sent: Wednesday, 18 November, 2020 19:46:10 > Subject: [horizon] Error when clicking instance detailed view after upgrading from ussuri to victoria > > Hello, > > I am a little lost here. Hopefully some of you nice people could help me with this issue please. > > We had an Openstack Ussuri deployment on Ubuntu 20.04 and upgraded to Victoria Release via cloud_archive repository > > Now when I click on any instance for a detailed view I get an error 500 with the following message: > > ==> /var/log/apache2/error.log <== > [Wed Nov 18 19:42:37.883040 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] /usr/lib/python3/dist-packages/django/contrib/staticfiles/templatetags/staticfiles.py:24: RemovedInDjango30Warning: {% load staticfiles %} is deprecated in favor of {% load static %}. > [Wed Nov 18 19:42:37.883091 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] warnings.warn( > [Wed Nov 18 19:42:37.886358 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] ERROR django.request Internal Server Error: /project/instances/25d58259-9d9d-4215-8fb6-521ff9a5befe/ > [Wed Nov 18 19:42:37.886400 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] Traceback (most recent call last): > [Wed Nov 18 19:42:37.886407 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 829, in _resolve_lookup > [Wed Nov 18 19:42:37.886412 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] current = current[bit] > [Wed Nov 18 19:42:37.886416 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] TypeError: 'Server' object is not subscriptable > [Wed Nov 18 19:42:37.886421 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] > [Wed Nov 18 19:42:37.886425 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] During handling of the above exception, another exception occurred: > [Wed Nov 18 19:42:37.886430 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] > [Wed Nov 18 19:42:37.886456 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] Traceback (most recent call last): > [Wed Nov 18 19:42:37.886460 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/openstack_dashboard/api/base.py", line 139, in __getattribute__ > [Wed Nov 18 19:42:37.886465 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return object.__getattribute__(self, attr) > [Wed Nov 18 19:42:37.886469 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] AttributeError: 'Server' object has no attribute 'OS-EXT-SRV-ATTR:instance_name' > [Wed Nov 18 19:42:37.886473 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] > [Wed Nov 18 19:42:37.886477 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] During handling of the above exception, another exception occurred: > [Wed Nov 18 19:42:37.886482 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] > [Wed Nov 18 19:42:37.886486 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] Traceback (most recent call last): > [Wed Nov 18 19:42:37.886501 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line 34, in inner > [Wed Nov 18 19:42:37.886647 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] response = get_response(request) > [Wed Nov 18 19:42:37.886651 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 145, in _get_response > [Wed Nov 18 19:42:37.886656 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] response = self.process_exception_by_middleware(e, request) > [Wed Nov 18 19:42:37.886661 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 143, in _get_response > [Wed Nov 18 19:42:37.886665 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] response = response.render() > [Wed Nov 18 19:42:37.886668 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/response.py", line 106, in render > [Wed Nov 18 19:42:37.886672 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] self.content = self.rendered_content > [Wed Nov 18 19:42:37.886676 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/response.py", line 83, in rendered_content > [Wed Nov 18 19:42:37.886680 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] content = template.render(context, self._request) > [Wed Nov 18 19:42:37.886684 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/backends/django.py", line 61, in render > [Wed Nov 18 19:42:37.886688 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.template.render(context) > [Wed Nov 18 19:42:37.886692 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 171, in render > [Wed Nov 18 19:42:37.886696 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self._render(context) > [Wed Nov 18 19:42:37.886700 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 163, in _render > [Wed Nov 18 19:42:37.886704 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.nodelist.render(context) > [Wed Nov 18 19:42:37.886708 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render > [Wed Nov 18 19:42:37.886717 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) > [Wed Nov 18 19:42:37.886721 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated > [Wed Nov 18 19:42:37.886725 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) > [Wed Nov 18 19:42:37.886730 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/loader_tags.py", line 150, in render > [Wed Nov 18 19:42:37.886863 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return compiled_parent._render(context) > [Wed Nov 18 19:42:37.886871 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 163, in _render > [Wed Nov 18 19:42:37.886875 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.nodelist.render(context) > [Wed Nov 18 19:42:37.886894 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render > [Wed Nov 18 19:42:37.886898 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) > [Wed Nov 18 19:42:37.886902 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated > [Wed Nov 18 19:42:37.886906 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) > [Wed Nov 18 19:42:37.886909 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/loader_tags.py", line 62, in render > [Wed Nov 18 19:42:37.886913 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] result = block.nodelist.render(context) > [Wed Nov 18 19:42:37.886917 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render > [Wed Nov 18 19:42:37.886945 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) > [Wed Nov 18 19:42:37.886973 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated > [Wed Nov 18 19:42:37.886978 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) > [Wed Nov 18 19:42:37.886982 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/loader_tags.py", line 62, in render > [Wed Nov 18 19:42:37.886986 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] result = block.nodelist.render(context) > [Wed Nov 18 19:42:37.886991 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render > [Wed Nov 18 19:42:37.886996 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) > [Wed Nov 18 19:42:37.887001 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated > [Wed Nov 18 19:42:37.887006 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) > [Wed Nov 18 19:42:37.887019 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 987, in render > [Wed Nov 18 19:42:37.887093 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] output = self.filter_expression.resolve(context) > [Wed Nov 18 19:42:37.887101 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 671, in resolve > [Wed Nov 18 19:42:37.887105 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] obj = self.var.resolve(context) > [Wed Nov 18 19:42:37.887109 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 796, in resolve > [Wed Nov 18 19:42:37.887113 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] value = self._resolve_lookup(context) > [Wed Nov 18 19:42:37.887117 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 858, in _resolve_lookup > [Wed Nov 18 19:42:37.887121 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] current = current() > [Wed Nov 18 19:42:37.887155 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/horizon/tabs/base.py", line 227, in render > [Wed Nov 18 19:42:37.887221 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return render_to_string(self.template_name, {"tab_group": self}) > [Wed Nov 18 19:42:37.887236 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/loader.py", line 62, in render_to_string > [Wed Nov 18 19:42:37.887242 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return template.render(context, request) > [Wed Nov 18 19:42:37.887246 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/backends/django.py", line 61, in render > [Wed Nov 18 19:42:37.887250 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.template.render(context) > [Wed Nov 18 19:42:37.887254 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 171, in render > [Wed Nov 18 19:42:37.887258 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self._render(context) > [Wed Nov 18 19:42:37.887262 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 163, in _render > [Wed Nov 18 19:42:37.887267 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.nodelist.render(context) > [Wed Nov 18 19:42:37.887272 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render > [Wed Nov 18 19:42:37.887276 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) > [Wed Nov 18 19:42:37.887280 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated > [Wed Nov 18 19:42:37.887284 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) > [Wed Nov 18 19:42:37.887288 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/loader_tags.py", line 150, in render > [Wed Nov 18 19:42:37.887293 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return compiled_parent._render(context) > [Wed Nov 18 19:42:37.887297 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 163, in _render > [Wed Nov 18 19:42:37.887382 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.nodelist.render(context) > [Wed Nov 18 19:42:37.887395 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render > [Wed Nov 18 19:42:37.887403 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) > [Wed Nov 18 19:42:37.887407 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated > [Wed Nov 18 19:42:37.887411 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) > [Wed Nov 18 19:42:37.887415 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/defaulttags.py", line 513, in render > [Wed Nov 18 19:42:37.887425 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.nodelist.render(context) > [Wed Nov 18 19:42:37.887429 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render > [Wed Nov 18 19:42:37.887434 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) > [Wed Nov 18 19:42:37.887438 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated > [Wed Nov 18 19:42:37.887443 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) > [Wed Nov 18 19:42:37.887448 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/defaulttags.py", line 309, in render > [Wed Nov 18 19:42:37.887453 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return nodelist.render(context) > [Wed Nov 18 19:42:37.887458 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render > [Wed Nov 18 19:42:37.887462 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) > [Wed Nov 18 19:42:37.887467 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated > [Wed Nov 18 19:42:37.887472 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) > [Wed Nov 18 19:42:37.887478 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/defaulttags.py", line 209, in render > [Wed Nov 18 19:42:37.887483 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] nodelist.append(node.render_annotated(context)) > [Wed Nov 18 19:42:37.887488 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated > [Wed Nov 18 19:42:37.887493 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) > [Wed Nov 18 19:42:37.887498 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 987, in render > [Wed Nov 18 19:42:37.887503 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] output = self.filter_expression.resolve(context) > [Wed Nov 18 19:42:37.887587 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 671, in resolve > [Wed Nov 18 19:42:37.887594 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] obj = self.var.resolve(context) > [Wed Nov 18 19:42:37.887598 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 796, in resolve > [Wed Nov 18 19:42:37.887602 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] value = self._resolve_lookup(context) > [Wed Nov 18 19:42:37.887606 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 858, in _resolve_lookup > [Wed Nov 18 19:42:37.887610 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] current = current() > [Wed Nov 18 19:42:37.887614 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/horizon/tabs/base.py", line 372, in render > [Wed Nov 18 19:42:37.887619 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return render_to_string(self.get_template_name(self.request), context) > [Wed Nov 18 19:42:37.887634 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/loader.py", line 62, in render_to_string > [Wed Nov 18 19:42:37.887638 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return template.render(context, request) > [Wed Nov 18 19:42:37.887642 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/backends/django.py", line 61, in render > [Wed Nov 18 19:42:37.887652 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.template.render(context) > [Wed Nov 18 19:42:37.887657 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 171, in render > [Wed Nov 18 19:42:37.887661 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self._render(context) > [Wed Nov 18 19:42:37.887665 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 163, in _render > [Wed Nov 18 19:42:37.887669 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.nodelist.render(context) > [Wed Nov 18 19:42:37.887673 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render > [Wed Nov 18 19:42:37.887678 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) > [Wed Nov 18 19:42:37.887682 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated > [Wed Nov 18 19:42:37.887686 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) > [Wed Nov 18 19:42:37.887691 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/defaulttags.py", line 302, in render > [Wed Nov 18 19:42:37.887696 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] match = condition.eval(context) > [Wed Nov 18 19:42:37.887707 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/defaulttags.py", line 876, in eval > [Wed Nov 18 19:42:37.887711 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.value.resolve(context, ignore_failures=True) > [Wed Nov 18 19:42:37.887729 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 671, in resolve > [Wed Nov 18 19:42:37.887734 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] obj = self.var.resolve(context) > [Wed Nov 18 19:42:37.887739 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 796, in resolve > [Wed Nov 18 19:42:37.887744 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] value = self._resolve_lookup(context) > [Wed Nov 18 19:42:37.887748 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 837, in _resolve_lookup > [Wed Nov 18 19:42:37.887753 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] current = getattr(current, bit) > [Wed Nov 18 19:42:37.887758 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/openstack_dashboard/api/base.py", line 139, in __getattribute__ > [Wed Nov 18 19:42:37.887763 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return object.__getattribute__(self, attr) > [Wed Nov 18 19:42:37.887767 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/openstack_dashboard/api/_nova.py", line 88, in has_extended_attrs > [Wed Nov 18 19:42:37.887772 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return any(getattr(self, attr) for attr in [ > [Wed Nov 18 19:42:37.887777 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/openstack_dashboard/api/_nova.py", line 88, in > [Wed Nov 18 19:42:37.887782 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return any(getattr(self, attr) for attr in [ > [Wed Nov 18 19:42:37.887786 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/openstack_dashboard/api/base.py", line 144, in __getattribute__ > [Wed Nov 18 19:42:37.887791 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return getattr(self._apiresource, attr) > [Wed Nov 18 19:42:37.887795 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/novaclient/base.py", line 176, in __getattr__ > [Wed Nov 18 19:42:37.887800 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] raise AttributeError(k) > [Wed Nov 18 19:42:37.887805 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] AttributeError: OS-EXT-SRV-ATTR:instance_name > > > Thanks in advance, > > Stefan Bujack > From balazs.gibizer at est.tech Fri Nov 20 13:54:50 2020 From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer) Date: Fri, 20 Nov 2020 14:54:50 +0100 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: Message-ID: On Thu, Nov 19, 2020 at 13:07, Balázs Gibizer wrote: > > > On Wed, Nov 18, 2020 at 11:24, Dan Smith wrote: >> That leads me to the first action item I think we need: >> >> ACTION 1: Make the wsgi app able to use something other than >> nova.conf >> >> All of our other services support a --config-file flag, and I don't >> see >> why we wouldn't allow this if it's necessary for deployments. In the >> pure API arrangement, it shouldn't really be necessary to change >> this, >> but clearly you may need to have multiple API workers with different >> configs, as is the case with metadata-per-cell, or even potentially >> some >> admin-focused private API endpoint. If it makes it easier for >> deployment >> tools to start the API workers with a specific config file, we should >> let them do that. You can already work around that hard-coded >> filename >> by setting OS_NOVA_CONFIG_DIR to something other than /etc/nova, but >> we >> shouldn't require them to create directories just to have separate >> configs. > > I will look into this change and propose patch a patch. > >> >> The next item is related: >> >> ACTION 2: We need to document a minimal viable config for each >> service >> >> Ollie points out that, obviously, handing the deployer a config >> reference with 1.21 bajillion config options does not clearly >> indicate >> which services need which thing, and especially, which things are >> _not_allowed_ to be set for a service (such as db credentials on the >> compute). We can't feasibly audit every config option we have, but it >> would be very helpful to have a reference that shows what a >> completely >> minimal configuration for each service looks like. We could do that >> by >> tagging services per config options (which I suggested earlier, and >> would still be good) but I think maybe a standalone document would be >> easier for people to follow. > > I've opened a doc bug to track the minimal config documentation work: > https://bugs.launchpad.net/nova/+bug/1904179 > But I would like to get help from others to start proposing this doc. Dan started the documentation work here https://review.opendev.org/#/c/763412/ > >> >> Now, on to the question about the hard-fail patch for compute: >> >> https://review.opendev.org/#/c/762176/ >> >> The Nova devs have wanted people to _not_ have db credentials in the >> config file that nova-compute can see for a "Very Long Time." We have >> even made some assumptions in the code that rely on these credentials >> being not set on the compute, which is at least partially why we're >> having this conversation (again) now. >> >> Despite the fact that nobody *should* be setting these credentials in >> their config file, we know that at in least some circumstances, they >> are. TripleO is setting them (always I think?) because puppet-nova >> does >> that. OSA has said that they're setting them somewhat incidentally >> when >> they do all-in-one deployments. The latter is unlikely to affect any >> real deployments, but the former definitely _will_, and anyone else >> that >> isn't present in this discussion may be including credentials >> unnecessarily, which we will break when we merge that patch. Thus, I >> think that, even though it feels long overdue for devs, the most >> prudent >> and cautious approach will be to: >> >> ACTION 3: Not merge that hard fail until X >> >> We have the warning, we have the reno. We expect that the deployment >> tools will be working to eliminate the credentials for the compute >> config, but merging that will make it an emergency for them. We've >> waited years at this point, we can wait one more cycle for safety. As >> Ollie pointed out, we've not been super clear about messaging this, >> despite it being a well-worn assumption amongst the developers for a >> long time. > > I'm OK not to merge the breaking patch in W. I've pushed a patch for the X cycle with a big Workflow -1 https://review.opendev.org/#/c/763559/ > >> >> To aid in smoking out any of the jobs or configs that deployment >> tools >> may still have which will break when we merge that patch, we should >> also >> consider: >> >> ACTION 4: A workaround flag to opt-in to the strict checking >> >> Basically, this would be a one or two-cycle workaround, which when >> enabled, would opt-in to the (above) behavior of causing compute to >> fail >> on startup if db credentials are present. This would allow the >> deployment tool maintainers, as well as people responsible for CI >> jobs >> to smoke test the new behavior early, before we merge it and cause an >> emergency for them. We can set this as on by default in our devstack >> jobs to signal that it is good with the new behavior, and also >> encourage >> the other deployment projects to set it as well once they're >> generating >> clean configs for their nova-computes. Once we merge the patch to >> actually fail all the time, we can remove this workaround config, >> according to the original intent of the workarounds group, that those >> flags are short-lived. >> >> We could do this by altering gibi's patch to only fail if the >> workaround >> is enabled, and then follow up in X by removing the workaround check. > > I will make the suggested changes in my patch. I've updated the patch with the workaround config option: https://review.opendev.org/#/c/762176 Cheers, gibi From mrunge at matthias-runge.de Fri Nov 20 14:48:17 2020 From: mrunge at matthias-runge.de (Matthias Runge) Date: Fri, 20 Nov 2020 15:48:17 +0100 Subject: [telemetry] wallaby cycle planning session In-Reply-To: References: Message-ID: <8e014d3a-d0b8-b05f-500e-97759e9cb22d@matthias-runge.de> On 17/11/2020 08:22, Matthias Runge wrote: > Good morning, > > quick reminder, if you are interested in telemetry and its future or > fate, please participate in the doodle[3]. > > Thank you. Hi, as result, we will be meeting next Friday (Nov. 27 at 4PM CET, that is 10 AM US Eastern). If it works for you, let's use this bluejeans channel[4] for the discussion. For ideas, questions and an agenda, there is the etherpad[5]. See you there [4] https://redhat.bluejeans.com/u/mrunge/ [5] https://etherpad.opendev.org/p/telemetry-wallaby-topics > > On 12/11/2020 11:25, Matthias Runge wrote: >> Hi there, >> >> one of the biggest challenges for the telemetry stack is currently the >> state of gnocchi, which is... >> undefined/unfortunate/under-contributed/...? >> >> Telemetry started long time ago as a simple component ceilometer, >> which was split into several components ceilometer, aodh, panko, and >> gnocchi. >> Julien wrote a story about this some time ago[1]. >> >> There has also been an attempt to fork gnocchi back to OpenStack[2]. >> >> To my knowledge, the original contributors are not paid anymore to >> work on gnocchi, and at the same time, moving on to do something else >> is totally fine. >> >> However, I am not sure if we (in OpenStack Telemetry) should or could >> maintain in addition to the rest of the telemetry stack a time-series >> database. I'd like to discuss this during a call. >> >> Please select time(s) that suit you best in this poll[3]. >> >> If you have questions or hints, don't hesitate to contact me. >> >> Thank you, >> Matthias >> >> [1] >> https://julien.danjou.info/lessons-from-openstack-telemetry-deflation/ >> [2] https://review.opendev.org/#/c/744592/ >> [3] https://doodle.com/poll/uqq328x5shr43awy >> > > From smooney at redhat.com Fri Nov 20 15:09:28 2020 From: smooney at redhat.com (Sean Mooney) Date: Fri, 20 Nov 2020 15:09:28 +0000 Subject: [neutron] Floating ips instances not appear in tcpdump In-Reply-To: <1B1F2725-083F-4138-B760-1865E91E9D24@getmailspring.com> References: <5ac56ebf4bb5b516e691c1be1e2ed697799544ac.camel@redhat.com> <1B1F2725-083F-4138-B760-1865E91E9D24@getmailspring.com> Message-ID: On Fri, 2020-11-20 at 11:41 +0100, Cristina Mayo wrote: > I'm using installation guides with the self service network option (that includes ML2 plugin and linux bridge agent): > https://docs.openstack.org/neutron/train/install/install-ubuntu.html ( > https://link.getmailspring.com/link/1B1F2725-083F-4138-B760-1865E91E9D24 at getmailspring.com/0?redirect=https%3A%2F%2Fdocs.openstack.org%2Fneutron%2Ftrain%2Finstall%2Finstall-ubuntu.html&recipient=c21vb25leUByZWRoYXQuY29t > ) > What I mean is, for example, if I have an apache server running on an instance with a public ip address (floating ip). When I access to that apache > server from whatever external network and I capture the traffic on the instance, all packages come from the same IP. that is not how neutron shoudl work by defualt. it sould like you have set up a nat on the external interface. how did you connect the external interface to the the outside world. normally you would create a neutron external network and attach and attach your tenats router to that network. you would then configre the subnet of that external network on your infracture routere assigning your phyical router the gateway ip adress of the network. basically did you nat the traffic to the host https://www.rdoproject.org/networking/networking-in-too-much-detail/#network-host-external-traffic-kl e.g. something like this ip addr add 172.24.4.225/28 dev br-ex # iptables -A FORWARD -d 172.24.4.224/28 -j ACCEPT # iptables -A FORWARD -s 172.24.4.224/28 -j ACCEPT # iptables -t nat -I POSTROUTING 1 -s 172.24.4.224/28 -j MASQUERADE or did you add the interface to the birdge like this ovs-vsctl add-port br-ex eth2 that how you would do it for ovs but for linux bridge its similar. https://docs.openstack.org/install-guide/launch-instance-networks-provider.html descibes how to configre proder network with linux brdige my best guess is that you have assinged the external netwrok gateway ip to the openstack contoler with ip 172.24.4.100 and that is nating the traffic. > I supposed that the controller node is retransmitting the packages and putting its ip address on them. > I capture some packets with tcpdump in this openstack instance with a public ip (floating_ip), for example: 172.24.4.228/32 ( > https://link.getmailspring.com/link/1B1F2725-083F-4138-B760-1865E91E9D24 at getmailspring.com/1?redirect=172.24.4.228%2F32&recipient=c21vb25leUByZWRoYXQuY29t > ) and I have a controller node with a public IP, for example 172.24.4.100/32, ( > https://link.getmailspring.com/link/1B1F2725-083F-4138-B760-1865E91E9D24 at getmailspring.com/2?redirect=172.24.4.228%2F32&recipient=c21vb25leUByZWRoYXQuY29t > ) the traces of traffic are something like this, but they should have others external sources IPs: > > # tcpdump tcp and port 443 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ens7, link-type EN10MB > (Ethernet), capture size 262144 bytes > 13:21:17.272668 IP 172.24.4.100 ( > https://link.getmailspring.com/link/1B1F2725-083F-4138-B760-1865E91E9D24 at getmailspring.com/3?redirect=172.24.4.228%2F32&recipient=c21vb25leUByZWRoYXQuY29t > ): ( > https://link.getmailspring.com/link/1B1F2725-083F-4138-B760-1865E91E9D24 at getmailspring.com/4?redirect=172.24.4.228%2F32&recipient=c21vb25leUByZWRoYXQuY29t)49718 >  ( > https://link.getmailspring.com/link/1B1F2725-083F-4138-B760-1865E91E9D24 at getmailspring.com/5?redirect=hermes.gsic.uva.es.49718&recipient=c21vb25leUByZWRoYXQuY29t > ) > 172.24.4.228.https: Flags [S], seq 3072401769, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 911923475 ecr 0,sackOK,eol], length 0 > 13:21:17.272787 IP 172.24.4.228.https > 172.24.4.100 ( > https://link.getmailspring.com/link/1B1F2725-083F-4138-B760-1865E91E9D24 at getmailspring.com/6?redirect=172.24.4.228%2F32&recipient=c21vb25leUByZWRoYXQuY29t > ): ( > https://link.getmailspring.com/link/1B1F2725-083F-4138-B760-1865E91E9D24 at getmailspring.com/7?redirect=172.24.4.228%2F32&recipient=c21vb25leUByZWRoYXQuY29t)49718 > : ( > https://link.getmailspring.com/link/1B1F2725-083F-4138-B760-1865E91E9D24 at getmailspring.com/8?redirect=hermes.gsic.uva.es.49718%3A&recipient=c21vb25leUByZWRoYXQuY29t > ) Flags [S.], seq 678353364, ack 3072401770, win 64308, options [mss 1410,sackOK,TS val 246556960 ecr 911923475,nop,wscale 7], length 0 > 13:21:17.273556 IP 172.24.4.10 ( > https://link.getmailspring.com/link/1B1F2725-083F-4138-B760-1865E91E9D24 at getmailspring.com/9?redirect=172.24.4.228%2F32&recipient=c21vb25leUByZWRoYXQuY29t)0 > : ( > https://link.getmailspring.com/link/1B1F2725-083F-4138-B760-1865E91E9D24 at getmailspring.com/10?redirect=172.24.4.228%2F32&recipient=c21vb25leUByZWRoYXQuY29t)49718 >  ( > https://link.getmailspring.com/link/1B1F2725-083F-4138-B760-1865E91E9D24 at getmailspring.com/11?redirect=hermes.gsic.uva.es.49718&recipient=c21vb25leUByZWRoYXQuY29t > ) > 172.24.4.228.https: Flags [.], ack 1, win 2053, options [nop,nop,TS val 911923476 ecr 246556960], length 0 > > So, I can't filter the traffic (in this case http/https) received in the openstack instance because all have the same IP address. The only way that > I can see the original ips are capturing packages on the controller node. > I don't have a lot experienced and I'd like to understand it. I hope I have explained better than before. From gmann at ghanshyammann.com Fri Nov 20 15:52:50 2020 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 20 Nov 2020 09:52:50 -0600 Subject: [Monasca][Openstack-Helm][Openstacksdk][Watcher] Action required: Gerrit code audit In-Reply-To: References: Message-ID: <175e65bb2c1.10c0d524f492196.2261310904108658019@ghanshyammann.com> Updates: Only 4 projects left for audit. - https://etherpad.opendev.org/p/code-audit-gerrit-breach-tracker Let us know if you need any assistance or update if you already did and not posted on ML yet. -gmann ---- On Mon, 16 Nov 2020 09:45:04 -0600 Mohammed Naser wrote ---- > Hello there, > > As per the `service-announce` on October 20 regarding Gerrit Outage > Update email http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html, > all project teams are required to audit changes for projects from > 2020-10-01 to 2020-10-21. I'm reaching out to those projects in > particular who the TC believes have not completed their audit yet. > > Let us know if you need any type of assistance in completing the audit. > > In case you didn’t know you needed to do this, feel free to reach out > for support. > > Regards, > Mohammed > > -- > Mohammed Naser > VEXXHOST, Inc. > > From fungi at yuggoth.org Fri Nov 20 16:19:45 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 20 Nov 2020 16:19:45 +0000 Subject: [all][diversity] IRC Channel Renames In-Reply-To: References: <20201119223719.vhit7ipanumckwvu@yuggoth.org> Message-ID: <20201120161945.ge4rg6ul775oayao@yuggoth.org> On 2020-11-19 15:53:09 -0800 (-0800), Kendall Nelson wrote: [...] > Yeah I was planning to post there too once I had some feedback > here, but I can post it there sooner than later too. Nah, it's fine, so long as we make sure it eventually also gets discussed there before we take any action. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From thierry at openstack.org Fri Nov 20 17:02:50 2020 From: thierry at openstack.org (Thierry Carrez) Date: Fri, 20 Nov 2020 18:02:50 +0100 Subject: [Monasca][Openstack-Helm][Openstacksdk][Watcher] Action required: Gerrit code audit In-Reply-To: <175e65bb2c1.10c0d524f492196.2261310904108658019@ghanshyammann.com> References: <175e65bb2c1.10c0d524f492196.2261310904108658019@ghanshyammann.com> Message-ID: Ghanshyam Mann wrote: > Updates: Only 4 projects left for audit. > > - https://etherpad.opendev.org/p/code-audit-gerrit-breach-tracker I looked up all patches for openstackSDK and could not find anything malicious there. -- Thierry Carrez (ttx) From pramchan at yahoo.com Fri Nov 20 17:04:48 2020 From: pramchan at yahoo.com (prakash RAMCHANDRAN) Date: Fri, 20 Nov 2020 17:04:48 +0000 (UTC) Subject: [openstack] [Interop] Todays Friday weekly meeting cancelled - will meet next week same time same meetpad References: <1277171602.330104.1605891888845.ref@mail.yahoo.com> Message-ID: <1277171602.330104.1605891888845@mail.yahoo.com> Hi all,We have gerrit access issues for any  Interop WG activity to be possible for Victoria cycle. Will meet next Friday 10 AM PST instead  refer: [service-announce] review.opendev.org Gerrit outage and upgrade 15:00UTC November 20 to 01:00UTC November 23, 2020 | | | | [service-announce] review.opendev.org Gerrit outage and upgrade 15:00UTC... | | | Please add your items if any for next week 27th NovOpenDev Etherpad | | | | OpenDev Etherpad | | | ThanksFor Interop WGPrakash -------------- next part -------------- An HTML attachment was scrubbed... URL: From gagehugo at gmail.com Fri Nov 20 18:09:53 2020 From: gagehugo at gmail.com (Gage Hugo) Date: Fri, 20 Nov 2020 12:09:53 -0600 Subject: [Freezer][Keystone][Mistral][Monasca][Murano][Openstack-Chef][Openstack-Helm][Openstacksdk][Trove][Watcher][Zun] Action required: Gerrit code audit In-Reply-To: References: Message-ID: No suspicious changes noted for openstack-helm repos. On Mon, Nov 16, 2020 at 9:45 AM Mohammed Naser wrote: > Hello there, > > As per the `service-announce` on October 20 regarding Gerrit Outage > Update email > http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html > , > all project teams are required to audit changes for projects from > 2020-10-01 to 2020-10-21. I'm reaching out to those projects in > particular who the TC believes have not completed their audit yet. > > Let us know if you need any type of assistance in completing the audit. > > In case you didn’t know you needed to do this, feel free to reach out > for support. > > Regards, > Mohammed > > -- > Mohammed Naser > VEXXHOST, Inc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephenfin at redhat.com Fri Nov 20 18:14:52 2020 From: stephenfin at redhat.com (Stephen Finucane) Date: Fri, 20 Nov 2020 18:14:52 +0000 Subject: [nova] How best to provide virtio-based input devices? In-Reply-To: <3138d040-2d53-059b-2f69-c5a8d0937840@gmail.com> References: <1a1b556fb4c832d15067991741deaedb71c6fbad.camel@redhat.com> <3138d040-2d53-059b-2f69-c5a8d0937840@gmail.com> Message-ID: <656b5979962963ff3918d5e0a2c12906140ff6d0.camel@redhat.com> On Wed, 2020-11-18 at 16:12 -0800, melanie witt wrote: > On 11/16/20 02:41, Stephen Finucane wrote: > > On Thu, 2020-11-12 at 17:09 -0800, melanie witt wrote: > > > Needless to say, I don't like this idea and prefer we took > > > another > > > tack > > > and kept 'hw_input_bus'  but didn't build on 'hw_pointer_model' > > > and > > > instead "deprecated" it. We can't really ever remove the an image > > > metadata property, since that would be a breaking upgrade, which > > > means > > > we'll eventually be left with effectively dead code to maintain > > > forever. However, I don't think that's a big deal. > > > 'hw_pointer_model=usbtablet' is already on a path to obsolescence > > > as > > > the Q35 machine type slowly becomes the default on x86 hosts and > > > the > > > use of non-x86 hosts grows since neither support PS2 and must use > > > a > > > USB-based input device. In addition, I think the extrapolation of > > > 'virtiotablet' to mean also virtio-based keyboard is unclear and > > > leaves > > > a gaping hole w.r.t. requesting USB-based keyboards on non- > > > AArch64 > > > hosts (where it's currently added by default), since we don't > > > currently > > > do this extrapolation and introducing it would be breaking change > > > on > > > x86 hosts (instances would suddenly switch from PS2-based > > > keyboards > > > to > > > USB-based ones). > > For some reason your email didn't quote my inline replies when you > replied back, so I'm going to label them for clarity. Looks like Evolution has broken plain text editing :( Apologies. > melwitt: > > If I understand correctly, we do choose the "best fit" keyboard > > based > > on architecture, independent of the requested hw_pointer_model, > > today. > stephenfin: > > Not quite. libvirt on x86 will automatically add a PS2 mouse and > > keyboard (even if you request something else) because that's what > > QEMU > > does. On all other platforms (to the best of my knowledge, based on > > Kashyap quizzing a handful of multi-arch libvirt devs), this must > > be > > done manually. We currently only do this for AArch64, through the > > non- > > configurable addition of a USB keyboard [1]. There is currently no > > way > > to request e.g. a USB or virtio keyboard on any architecture. > > > > [1] https://github.com/openstack/nova/commit/b92e3bc95fd > > Hm, OK, apologies for my lack of familiarity here. So there are > really > three things here: tablet, mouse, and keyboard. And the user today > can > choose hw_pointer_model as None (leave it to default behavior) or > usbtablet which sets the input.type=tablet and the input.bus=usb. And > then the mouse and keyboard are set to whatever they have to be given > the architecture. Sort of. As above, you'll get the PS2 keyboard for free on x86. You'll get a USB keyboard on AArch64. You won't get anything on any other arch. > melwitt: > > It feels like it would be simpler to continue doing that and add a > > virtio choice to hw_pointer_model and let the driver pick the > > "best" > > keyboard to go along with that. Is it your view that having the > > > driver choose a virtio keyboard if hw_pointer_model=virtiotablet > > > is > > > inconsistent with the existing "best fit" keyboard selection > > > behavior? > > stephenfin: > > My concerns are twofold. Firstly, having the value of > > 'hw_pointer_model' influence the keyboard bus is poor UX, since > > this > > "feature" is not at all apparent from the property name. Secondly, > > 'hw_pointer_model' is a poorly designed property, given it > > configured > > the bus as well as the model, munging the two. > > > > To be clear, I agree that having different buses for keyboard and > > pointer makes no sense. There's no reason they shouldn't be the > > same. > > I'm just saying that configuring the bus for input devices via an > > appropriately named 'hw_input_bus' image metadata property makes > > much > > more sense that maybe getting one configured magically based on the > > "pointer model" in use. > > OK, so the introduction of virtio would be the first time that we > would > be able to set all of tablet, mouse, and keyboard to the same bus. > What > if they don't want all three input devices, could it cause any > undesirable behavior for them? You don't have any choice: if you have a graphical console, you need a pointer (mouse or tablet) and you need a keyboard for it to be usable. Conversely, if you don't have a graphical console, then we've no need to add either. If a user didn't want a mouse and keyboard then they can and should disable graphical consoles. > And then if they set hw_input_bus=usb for libvirt on x86 they'd get a > USB tablet, a PS2 mouse, and a PS2 keyboard and on AArch64 they'd get > a > USB tablet, ? mouse, and USB keyboard. No, on x86 you'd get a USB tablet and keyboard, and a PS2 mouse PS2 keyboard. This is because there isn't currently a way to disable the PS2 devices in libvirt/QEMU. However, this is not an issue since the guest OS will default to using the USB-based devices (or so danpb tells me). Also note that this is very similar to how things currently work with 'hw_pointer_model=usbtablet': setting this means you'll get a USB tablet (but not keyboard), and a PS2 mouse and keyboard. On AArch64 and any other non-x86 host, they'd get simply a USB tablet and a USB keyboard because libvirt doesn't have that QEMU quirk to work with. > I dunno, it's all pretty confusing IMHO. My point in my last reply > was > that for the libvirt on x86 case, if the user sets hw_input_bus=usb, > how > would they know they're really only specifying the tablet? Today they > use hw_pointer_model=usbtablet which makes it clear what they have > control over. I acknowledge that for hw_input_bus=virtio, things all > line up nicely, but for everything else, it doesn't necessarily. As above, they're not. hw_input_bus means USB keyboard and tablet on any host. The only arch that will do something weird is x86, where we have those pesky PS2 remnants that we can't get rid of. > This makes me think it would be clearest and least confusing (IMHO) > to > add a new option like dansmith mentioned, hw_pointer_model=virtio. > That > way it's not talking only about a tablet but generically just > 'virtio' > and then all of tablet, mouse, and keyboard get added with > bus=virtio. > melwitt: > >  From what I understand, the pointer is the only user selection we > > can guarantee and the keyboard is architecture dependent. > > stephenfin: > > Again, not really. There isn't an analog for pointer vs. mouse when > > it > > comes to keyboards. The keyboard isn't architecture dependent. What > > is > > architecture dependent is whether you get a keyboard and mouse by > > default (yes on x86, in the form of a PS2 mouse and keyboard, and > > no > > for everyone else). > > melwitt: > > > If we "deprecated" hw_pointer_model and introduced hw_input_bus, > > > how does > > > the user know which thing (pointer or keyboard) they are > > > specifying? > > > If users can't actually choose the keyboard and can only choose > > > the pointer, > > wouldn't presenting a selection of a generic "hw_input_bus" be more > > confusing > > > than hw_pointer_model? > > stephenfin: > > They can choose the _bus_ that the keyboard uses. There's an > > assumption > > here that if you request a graphics device (VNC, SPICE, ...) then > > you > > will get a keyboard and tablet input devices, because that graphics > > device is unusable otherwise. There is also an assumption (based on > > dansmith's comments about mouse being only used for legacy compat > > reasons) that the user will never want to explicitly request a > > 'mouse' > > pointer model and should therefore get 'tablet' by default. Based > > on > > these two assumptions, the only thing remaining is to decide how > > the > > keyboard and tablet devices will be attached to the > > guest...achieved > > via a sensibly named 'hw_input_bus' image metadata property. That > > seems > > reasonable to me. > > I hope I'm not woefully wrong here again, but IIUC they can't choose > the > bus the mouse and keyboard uses for libvirt on x86, they get PS2 > regardless. This is why I feel like hw_input_bus as a replacement for > hw_pointer_model is not clear. It's only guaranteed to be used for > the > tablet bus. > > I'm sorry I'm not seeing how hw_pointer_model=virtio isn't the > clearest, > least confusing way to add virtio. (Or maybe > hw_pointer_model=virtiotabletmousekeyboard ?!) > > Thanks for taking the time to explain the technical details around > this > area of the code. I think I now understand your point of view since > the > name of hw_pointer_model doesn't nicely convey the > tablet+mouse+keyboard > setting when it comes to virtio. On the flip side of that, I feel > like > hw_input_bus=usb when it's only going to be honored for the tablet > for > libvirt on x86 seems even less nice. Given the above, do you still have the same concerns around using hw_input_bus? Cheers, Stephen > This is all just MHO. If most other people think that hw_input_bus is > the clearer and more user-friendly way to present this config, then I > will of course accept the consensus. > > Cheers, > -melanie > > > > We need to decide what approach to go for before I rework this. > > > If > > > anyone has input, particularly operators that think they'd use > > > this > > > feature, I'd love to hear it so that I can t̶e̶l̶l̶ > > > ̶d̶a̶n̶s̶m̶i̶t̶h̶ > > > ̶t̶o̶ ̶s̶h̶o̶v̶e̶ ̶i̶t̶ come to the best possible solution ;-) > > > Feel > > > free to either reply here or on the review [1]. > > > > > > Cheers, > > > Stephen > > > > > > [1] https://review.opendev.org/#/c/756552/ > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From whayutin at redhat.com Fri Nov 20 18:22:51 2020 From: whayutin at redhat.com (Wesley Hayutin) Date: Fri, 20 Nov 2020 11:22:51 -0700 Subject: [heat][tripleo] upstream heat ci job dashboard Message-ID: Greetings, Just an FYI.. Adriano has put together a nice dashboard for getting a high level view of the upstream CI jobs for heat [1]. Thanks Adriano, well done! [1] http://dashboard-ci.tripleo.org/d/TsdDSjtMz/upstream-heat?orgId=1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jungleboyj at gmail.com Fri Nov 20 18:46:40 2020 From: jungleboyj at gmail.com (Jay Bryant) Date: Fri, 20 Nov 2020 12:46:40 -0600 Subject: [all][diversity] IRC Channel Renames In-Reply-To: References: <20201119223719.vhit7ipanumckwvu@yuggoth.org> Message-ID: On 11/19/2020 5:53 PM, Kendall Nelson wrote: > > > On Thu, Nov 19, 2020, 2:42 PM Amy Marrich > wrote: > > That makes sense plus Jeremy's suggestions. > > Amy > > On Thu, Nov 19, 2020 at 4:40 PM Jeremy Stanley > wrote: > > On 2020-11-19 14:09:34 -0800 (-0800), Kendall Nelson wrote: > > Below is a list of the channels that come to mind and > proposed new > > channel names. Please add to the list or suggest alternative > names > > if you hate what I've come up with. My goal is to process these > > renames by the end of the year. > > > > - #openstack-ptg  -> #oif-ptg > > - #openstack-forum -> #oif-forum > > - #openstack-diversity -> #oif-diversity > > - #openstack-board -> #oif-board > > - #openstack-foundation -> #oif-foundation > > I might instead suggest moving the last one as so: > > - #openstack-foundation -> #oif > > And there's this recent addition, not sure if it needs to stick > around, but... > > - #openinfra-summit -> #oif-summit > > > I'm good with both of these! > > > Also it feels sort of weird to be talking about this on the > openstack-discuss ML instead of the foundation ML, but I guess it > can't hurt to solicit ideas here first before starting it up there > too. > > > Yeah I was planning to post there too once I had some feedback here, > but I can post it there sooner than later too. > > -- > Jeremy Stanley > > > -Kendall (diablo_rojo) All, I support the above recommendations (Kendall + Jeremy's).  Think it is good to make the channels more inclusive. Thanks! Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From gagehugo at gmail.com Fri Nov 20 18:55:00 2020 From: gagehugo at gmail.com (Gage Hugo) Date: Fri, 20 Nov 2020 12:55:00 -0600 Subject: [Security-SIG] No meeting next week Message-ID: Hello everyone, Due to Thanksgiving in the US next week, the Security SIG meeting will be cancelled, we will meet again at our regular time on Dec 3rd. Hope everyone has a good holiday and stays safe! -------------- next part -------------- An HTML attachment was scrubbed... URL: From gagehugo at gmail.com Fri Nov 20 18:55:46 2020 From: gagehugo at gmail.com (Gage Hugo) Date: Fri, 20 Nov 2020 12:55:46 -0600 Subject: [openstack-helm] No Meeting Next Week Message-ID: Hello everyone, Due to Thanksgiving in the US next week, the openstack-helm meeting will be cancelled, we will meet again at our regular time on Dec 1st. Hope everyone has a good holiday and stays safe! -------------- next part -------------- An HTML attachment was scrubbed... URL: From melwittt at gmail.com Fri Nov 20 21:46:35 2020 From: melwittt at gmail.com (melanie witt) Date: Fri, 20 Nov 2020 13:46:35 -0800 Subject: [nova] How best to provide virtio-based input devices? In-Reply-To: <656b5979962963ff3918d5e0a2c12906140ff6d0.camel@redhat.com> References: <1a1b556fb4c832d15067991741deaedb71c6fbad.camel@redhat.com> <3138d040-2d53-059b-2f69-c5a8d0937840@gmail.com> <656b5979962963ff3918d5e0a2c12906140ff6d0.camel@redhat.com> Message-ID: <00566464-66a6-1579-d0d2-f2784f4f6c79@gmail.com> On 11/20/20 10:14, Stephen Finucane wrote: > On Wed, 2020-11-18 at 16:12 -0800, melanie witt wrote: >> On 11/16/20 02:41, Stephen Finucane wrote: >>> On Thu, 2020-11-12 at 17:09 -0800, melanie witt wrote: >> OK, so the introduction of virtio would be the first time that we would >> be able to set all of tablet, mouse, and keyboard to the same bus. What >> if they don't want all three input devices, could it cause any >> undesirable behavior for them? > > You don't have any choice: if you have a graphical console, you need a > pointer (mouse or tablet) and you need a keyboard for it to be usable. > Conversely, if you don't have a graphical console, then we've no need to > add either. If a user didn't want a mouse and keyboard then they can and > should disable graphical consoles. Ack, understood. >> And then if they set hw_input_bus=usb for libvirt on x86 they'd get a >> USB tablet, a PS2 mouse, and a PS2 keyboard and on AArch64 they'd get a >> USB tablet, ? mouse, and USB keyboard. > > No, on x86 you'd get a USB tablet and keyboard, and a PS2 mouse PS2 > keyboard. This is because there isn't currently a way to disable the PS2 > devices in libvirt/QEMU. However, this is not an issue since the guest > OS will default to using the USB-based devices (or so danpb tells me). > Also note that this is very similar to how things currently work with > 'hw_pointer_model=usbtablet': setting this means you'll get a USB tablet > (but not keyboard), and a PS2 mouse and keyboard. > > On AArch64 and any other non-x86 host, they'd get simply a USB tablet > and a USB keyboard because libvirt doesn't have that QEMU quirk to work > with. OK, this was something I didn't previously get. So, your proposal is that if you were to add hw_input_bus=usb you would also add the USB keyboard and USB mouse for x86. So you end up with USB tablet and keyboard and mouse on x86. You just also happen to have PS2 keyboard and mouse as well and they will not be defaulted. And then AArch64 would get USB tablet and keyboard and mouse with hw_input_bus=usb. I had been previously thinking the hw_input_bus addition would be a change in name only and not a change (additive change) of behavior as well. >> I'm sorry I'm not seeing how hw_pointer_model=virtio isn't the clearest, >> least confusing way to add virtio. (Or maybe >> hw_pointer_model=virtiotabletmousekeyboard ?!) >> >> Thanks for taking the time to explain the technical details around this >> area of the code. I think I now understand your point of view since the >> name of hw_pointer_model doesn't nicely convey the tablet+mouse+keyboard >> setting when it comes to virtio. On the flip side of that, I feel like >> hw_input_bus=usb when it's only going to be honored for the tablet for >> libvirt on x86 seems even less nice. > > Given the above, do you still have the same concerns around using > hw_input_bus? Now that I understand that the user's bus choice via hw_input_bus would indeed be honored for all of tablet, keyboard, and mouse for all architectures, I can acknowledge that hw_input_bus could be an improved name over hw_pointer_model. I still think the main, important user selectable bit is the pointer, so I don't think the hw_pointer_model name is so terrible. The remaining concern would be around the work users and operators would have to do to adopt the new name. Are you thinking that existing images just stay as-is and if users want virtio or all USB they can only get it via hw_input_bus=virtio or hw_input_bus=usb and that will facilitate use of the new image property? So the summary would be: * hw_pointer_model=usbtablet you still get a USB tablet and the rest is unselectable * hw_input_bus=usb you get USB everything * hw_input_bus=virtio you get virtio everything If this is the case, then I would say I'm no longer actively opposed to adding hw_input_bus image property to get virtio, but I'm still not sure whether it's worth the amount of change and new image property users need to learn, given that pointer is the main thing users care about and we already have the pointer property. I'll defer to others to decide whether it's worth it, as I'm ambivalent :) Cheers, -melanie >> This is all just MHO. If most other people think that hw_input_bus is >> the clearer and more user-friendly way to present this config, then I >> will of course accept the consensus. >> >> Cheers, >> -melanie >> >>>> We need to decide what approach to go for before I rework this. If >>>> anyone has input, particularly operators that think they'd use this >>>> feature, I'd love to hear it so that I can t̶e̶l̶l̶ ̶d̶a̶n̶s̶m̶i̶t̶h̶ >>>> ̶t̶o̶ ̶s̶h̶o̶v̶e̶ ̶i̶t̶ come to the best possible solution ;-) Feel >>>> free to either reply here or on the review [1]. >>>> >>>> Cheers, >>>> Stephen >>>> >>>> [1] https://review.opendev.org/#/c/756552/ >>>> >>>> >>>> >>> >>> >>> >> > From zigo at debian.org Sat Nov 21 01:38:54 2020 From: zigo at debian.org (Thomas Goirand) Date: Sat, 21 Nov 2020 02:38:54 +0100 Subject: [telemetry] wallaby cycle planning session In-Reply-To: References: Message-ID: <0aa17d80-4bcd-eb66-41d6-5d9f0c5aa12b@debian.org> On 11/12/20 11:25 AM, Matthias Runge wrote: > Hi there, > > one of the biggest challenges for the telemetry stack is currently the > state of gnocchi, which is... undefined/unfortunate/under-contributed/...? > > Telemetry started long time ago as a simple component ceilometer, which > was split into several components ceilometer, aodh, panko, and gnocchi. > Julien wrote a story about this some time ago[1]. > > There has also been an attempt to fork gnocchi back to OpenStack[2]. > > To my knowledge, the original contributors are not paid anymore to work > on gnocchi, and at the same time, moving on to do something else is > totally fine. > > However, I am not sure if we (in OpenStack Telemetry) should or could > maintain in addition to the rest of the telemetry stack a time-series > database. I'd like to discuss this during a call. Matthias, I'm not sure I will have time to join the call. So hopefully, you understand that I prefer email (also because I wont be able to contribute to the project, so maybe joining the call would be overkill). Could you list the alternatives? If not using Gnocchi, what other backend would you use? As an operator I need a timeseries which is: - free software - HA - able to scale - packaged or packagable in my distro I don't know any time series db (apart from Gnocchi) that check all the bullets above. Do you? On 11/20/20 3:48 PM, Matthias Runge wrote: > If it works for you, let's use this bluejeans channel[4] for the > discussion. Gosh, reading that you'd be using bluejeans, then definitively, I will not be able to join the call... :/ Cheers, Thomas Goirand (zigo) From zigo at debian.org Sat Nov 21 01:40:26 2020 From: zigo at debian.org (Thomas Goirand) Date: Sat, 21 Nov 2020 02:40:26 +0100 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: <661281605711741@mail.yandex.ru> References: <4211161605171577@mail.yandex.ru> <5971221605688542@mail.yandex.ru> <661281605711741@mail.yandex.ru> Message-ID: <55f9722d-dc81-c984-1991-30351d6231e0@debian.org> On 11/18/20 4:06 PM, Dmitriy Rabotyagov wrote: > Well, at least that does not work for nova then... uwsgi output and conf > [1], journalctl logs [2] >   >   > [1] http://paste.openstack.org/show/800158/ > [2] http://paste.openstack.org/show/800159/ I can assure you that what I wrote works. Look at the Neutron packages in Debian if you want to make sure of that... :) Thomas Goirand (zigo) From zigo at debian.org Sat Nov 21 01:47:23 2020 From: zigo at debian.org (Thomas Goirand) Date: Sat, 21 Nov 2020 02:47:23 +0100 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: Message-ID: <6feed46a-c1b8-74ac-f59a-d45b2bfefd67@debian.org> On 11/18/20 8:24 PM, Dan Smith wrote: > which things are > _not_allowed_ to be set for a service (such as db credentials on the > compute). I still don't understand why this is forbidden. Sure, I understand what people wrote: that it is a security problem. Can't nova-compute just *ignore* the db credentials, and then everyone is done with it, and moves on? That's a much more easy way to handle this problem, IMO. Cheers, Thomas Goirand (zigo) From fungi at yuggoth.org Sat Nov 21 14:26:39 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Sat, 21 Nov 2020 14:26:39 +0000 Subject: [telemetry] wallaby cycle planning session In-Reply-To: <0aa17d80-4bcd-eb66-41d6-5d9f0c5aa12b@debian.org> References: <0aa17d80-4bcd-eb66-41d6-5d9f0c5aa12b@debian.org> Message-ID: <20201121142639.2bmljzki4pjoye27@yuggoth.org> On 2020-11-21 02:38:54 +0100 (+0100), Thomas Goirand wrote: [...] > Gosh, reading that you'd be using bluejeans, then definitively, I will > not be able to join the call... :/ If it helps, I've been able to join Bluejeans calls with just Firefox (the version in debian/unstable at least), no proprietary browser extension or separate client needed. It may not be ideal, but it's worked for me in the past anyway. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From martin at chaconpiza.com Sun Nov 22 19:03:20 2020 From: martin at chaconpiza.com (Martin Chacon Piza) Date: Sun, 22 Nov 2020 20:03:20 +0100 Subject: [Monasca][Openstack-Helm][Openstacksdk][Watcher] Action required: Gerrit code audit In-Reply-To: <175e65bb2c1.10c0d524f492196.2261310904108658019@ghanshyammann.com> References: <175e65bb2c1.10c0d524f492196.2261310904108658019@ghanshyammann.com> Message-ID: Hi, I have reviewed all the patches merged between 2020-10-01 and 2020-10-20, I can confirm that these Monasca repos look OK. https://static.opendev.org/project/opendev.org/gerrit-diffs/openstack/monasca-agent.git/ https://static.opendev.org/project/opendev.org/gerrit-diffs/openstack/monasca-api.git/ https://static.opendev.org/project/opendev.org/gerrit-diffs/openstack/monasca-common.git/ https://static.opendev.org/project/opendev.org/gerrit-diffs/openstack/monasca-notification.git/ https://static.opendev.org/project/opendev.org/gerrit-diffs/openstack/monasca-persister.git/ https://static.opendev.org/project/opendev.org/gerrit-diffs/openstack/monasca-statsd.git/ https://static.opendev.org/project/opendev.org/gerrit-diffs/openstack/monasca-thresh.git/ https://static.opendev.org/project/opendev.org/gerrit-diffs/openstack/monasca-ui.git/ https://static.opendev.org/project/opendev.org/gerrit-diffs/openstack/python-monascaclient.git/ * I'm not following this repo, It looks ok for me, but maybe somebody could help to audit it: https://static.opendev.org/project/opendev.org/gerrit-diffs/openstack/puppet-monasca.git/ Thanks, Martin (chaconpiza) El vie, 20 de nov. de 2020 a la(s) 16:57, Ghanshyam Mann ( gmann at ghanshyammann.com) escribió: > Updates: Only 4 projects left for audit. > > - https://etherpad.opendev.org/p/code-audit-gerrit-breach-tracker > > Let us know if you need any assistance or update if you already did and > not posted on ML yet. > > -gmann > > > ---- On Mon, 16 Nov 2020 09:45:04 -0600 Mohammed Naser < > mnaser at vexxhost.com> wrote ---- > > Hello there, > > > > As per the `service-announce` on October 20 regarding Gerrit Outage > > Update email > http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html > , > > all project teams are required to audit changes for projects from > > 2020-10-01 to 2020-10-21. I'm reaching out to those projects in > > particular who the TC believes have not completed their audit yet. > > > > Let us know if you need any type of assistance in completing the audit. > > > > In case you didn’t know you needed to do this, feel free to reach out > > for support. > > > > Regards, > > Mohammed > > > > -- > > Mohammed Naser > > VEXXHOST, Inc. > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Sun Nov 22 22:39:02 2020 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Sun, 22 Nov 2020 16:39:02 -0600 Subject: [Monasca][Openstack-Helm][Openstacksdk][Watcher] Action required: Gerrit code audit In-Reply-To: References: <175e65bb2c1.10c0d524f492196.2261310904108658019@ghanshyammann.com> Message-ID: <175f21c4e44.120ac6d0d518498.8601254996452168351@ghanshyammann.com> ---- On Sun, 22 Nov 2020 13:03:20 -0600 Martin Chacon Piza wrote ---- > Hi, > I have reviewed all the patches merged between 2020-10-01 and 2020-10-20, I can confirm that these Monasca repos look OK. > > https://static.opendev.org/project/opendev.org/gerrit-diffs/openstack/monasca-agent.git/ > https://static.opendev.org/project/opendev.org/gerrit-diffs/openstack/monasca-api.git/ > https://static.opendev.org/project/opendev.org/gerrit-diffs/openstack/monasca-common.git/ > https://static.opendev.org/project/opendev.org/gerrit-diffs/openstack/monasca-notification.git/ > https://static.opendev.org/project/opendev.org/gerrit-diffs/openstack/monasca-persister.git/ > https://static.opendev.org/project/opendev.org/gerrit-diffs/openstack/monasca-statsd.git/ > https://static.opendev.org/project/opendev.org/gerrit-diffs/openstack/monasca-thresh.git/ > https://static.opendev.org/project/opendev.org/gerrit-diffs/openstack/monasca-ui.git/ > https://static.opendev.org/project/opendev.org/gerrit-diffs/openstack/python-monascaclient.git/ > > * I'm not following this repo, It looks ok for me, but maybe somebody could help to audit it: > > https://static.opendev.org/project/opendev.org/gerrit-diffs/openstack/puppet-monasca.git/ Thanks Martin for the audit and confirmation. puppet-monasca repo is under puppet-openstack project and audited by Takashi Kajinami on Oct 22 as part of puppet-openstack audit. -gmann > > Thanks, > Martin (chaconpiza) > > El vie, 20 de nov. de 2020 a la(s) 16:57, Ghanshyam Mann (gmann at ghanshyammann.com) escribió: > Updates: Only 4 projects left for audit. > > - https://etherpad.opendev.org/p/code-audit-gerrit-breach-tracker > > Let us know if you need any assistance or update if you already did and not posted on ML yet. > > -gmann > > > ---- On Mon, 16 Nov 2020 09:45:04 -0600 Mohammed Naser wrote ---- > > Hello there, > > > > As per the `service-announce` on October 20 regarding Gerrit Outage > > Update email http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html, > > all project teams are required to audit changes for projects from > > 2020-10-01 to 2020-10-21. I'm reaching out to those projects in > > particular who the TC believes have not completed their audit yet. > > > > Let us know if you need any type of assistance in completing the audit. > > > > In case you didn’t know you needed to do this, feel free to reach out > > for support. > > > > Regards, > > Mohammed > > > > -- > > Mohammed Naser > > VEXXHOST, Inc. > > > > > > From kennelson11 at gmail.com Mon Nov 23 01:48:45 2020 From: kennelson11 at gmail.com (Kendall Nelson) Date: Sun, 22 Nov 2020 17:48:45 -0800 Subject: [Monasca][Openstack-Helm][Openstacksdk][Watcher] Action required: Gerrit code audit In-Reply-To: References: <175e65bb2c1.10c0d524f492196.2261310904108658019@ghanshyammann.com> Message-ID: I also brought it up in our meeting last Thursday and gtema had looked through everything and didn't see anything suspect. The tracking etherpad should be up to date. -Kendall (diablo_rojo) On Fri, Nov 20, 2020, 9:04 AM Thierry Carrez wrote: > Ghanshyam Mann wrote: > > Updates: Only 4 projects left for audit. > > > > - https://etherpad.opendev.org/p/code-audit-gerrit-breach-tracker > I looked up all patches for openstackSDK and could not find anything > malicious there. > > -- > Thierry Carrez (ttx) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From licanwei_cn at 163.com Mon Nov 23 03:03:11 2020 From: licanwei_cn at 163.com (licanwei) Date: Mon, 23 Nov 2020 11:03:11 +0800 (GMT+08:00) Subject: [Watcher] Gerrit breach and commit audit In-Reply-To: References: <175e65bb2c1.10c0d524f492196.2261310904108658019@ghanshyammann.com> Message-ID: <57b9529d.4922.175f30e2486.Coremail.licanwei_cn@163.com> Sorry for the delay, following the request, I confirm that the Watcher repos look OK. Thanks! Canwei Li | | licanwei_cn | | 邮箱：licanwei_cn at 163.com | 签名由 网易邮箱大师 定制 On 11/23/2020 09:48, Kendall Nelson wrote: I also brought it up in our meeting last Thursday and gtema had looked through everything and didn't see anything suspect. The tracking etherpad should be up to date. -Kendall (diablo_rojo) On Fri, Nov 20, 2020, 9:04 AM Thierry Carrez wrote: Ghanshyam Mann wrote: > Updates: Only 4 projects left for audit. > > - https://etherpad.opendev.org/p/code-audit-gerrit-breach-tracker I looked up all patches for openstackSDK and could not find anything malicious there. -- Thierry Carrez (ttx) -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepa.kr at fingent.com Mon Nov 23 04:33:30 2020 From: deepa.kr at fingent.com (Deepa KR) Date: Mon, 23 Nov 2020 10:03:30 +0530 Subject: [Ussuri] Auto shutdown VM In-Reply-To: <14800219-BC67-4B94-88CE-81FE5D8A6AB2@fingent.com> References: <158621605687826@mail.yandex.com> <14800219-BC67-4B94-88CE-81FE5D8A6AB2@fingent.com> Message-ID: Hi Can see only shutting down, reason=crashed in libvirt/qemu logs .Nothing else . Couldn't find anything else in neutron logs as well On Wed, Nov 18, 2020 at 5:23 PM Deepa KR wrote: > Thanks for pointing out. Have 70 + vms and has issue with just 3 vms so i > am really confused > > Sent from my iPhone > > On 18-Nov-2020, at 1:56 PM, rui zang wrote: > >  > [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] *Received unexpected > event network-vif-unplugged-e97839a1-bbc4-4d26-af30-768ca3630ce9 for > instance with vm_state active and task_state None.* > > > Clearly the network virtual interface was somehow removed or unplugged. > What you should look into is OVS or whatever the network solution you are > using. > > > 18.11.2020, 01:44, "Deepa KR" : > >  Hi All > > We have a Openstack setup with the *Ussuri Version* and I am *regularly > facing auto shutdown of a few VMs (ubuntu16.04) randomly* . > If I restart then the instance is back . > > From logs I was able to see the messages below . > > WARNING nova.compute.manager [req-2a21d455-ac04-44aa-b248-4776e5109013 > 813f3fb52c434e38991bb90aa4771541 10b5279cb6f64ca19871f132a2cee1a3 - default > default] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] *Received > unexpected event network-vif-unplugged-e97839a1-bbc4-4d26-af30-768ca3630ce9 > for instance with vm_state active and task_state None.* > INFO nova.compute.manager [-] [instance: > 28cd861c-ef15-444a-a902-9cac643c72b5] VM Stopped (Lifecycle Event) > INFO nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - > - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] *During > _sync_instance_power_state the DB power_state (1) does not match the > vm_power_state from the hypervisor (4). Updating power_state in the DB to > match the hypervisor.* > syslog:Nov 13 07:01:07 fgshwbucehyp04 nova-compute[2680204]: 2020-11-13 > 07:01:07.684 2680204 WARNING nova.compute.manager > [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: > 28cd861c-ef15-444a-a902-9cac643c72b5] *Instance shutdown by itself. > Calling the stop API. Current vm_state: active, current task_state: None, > original DB power_state: 1, current VM power_state: 4* > nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - > -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] *Instance is already > powered off in the hypervisor when stop is called.* > nova.virt.libvirt.driver [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - > - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] *Instance already > shutdown.* > nova.virt.libvirt.driver [-] [instance: > 28cd861c-ef15-444a-a902-9cac643c72b5] *Instance destroyed successfully.* > nova.compute.manager [req-7a0a0d03-e286-42f0-9e36-38a432f236f3 > d9ca03b9d0884d51a26a39b6c82f02eb 304d859c43df4de4944ca5623f7f455c - default > default] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Get console output > nova.virt.libvirt.driver [-] [instance: > 28cd861c-ef15-444a-a902-9cac643c72b5] *Instance destroyed successfully.* > > I searched a few blogs and forums but couldn't find a solution to it . > > Few mentioned to add s*ync_power_state_interval=-1 in * > */etc/nova/nova.conf *.But understood that this will help only when nova > stops vm. > But in this case vm itself is shutting down (*Instance shutdown by > itself. Calling the stop API*) > Also no memory issue in VM nor the hypervisor. > Also did apt-get upgrade . > > It would be great if anyone can shed light to this issue. > > Regards, > Deepa K R > > Sent from my iPhone > > -- Regards, Deepa K R | DevOps Team Lead USA | UAE | INDIA | AUSTRALIA -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature-1.gif Type: image/gif Size: 566 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_for_signature.png Type: image/png Size: 10509 bytes Desc: not available URL: From emiller at genesishosting.com Mon Nov 23 05:29:39 2020 From: emiller at genesishosting.com (Eric K. Miller) Date: Sun, 22 Nov 2020 23:29:39 -0600 Subject: [Ussuri] Auto shutdown VM In-Reply-To: References: <158621605687826@mail.yandex.com> <14800219-BC67-4B94-88CE-81FE5D8A6AB2@fingent.com> Message-ID: <046E9C0290DD9149B106B72FC9156BEA04814C0E@gmsxchsvr01.thecreation.com> > Can see only shutting down, reason=crashed in libvirt/qemu logs .Nothing else . > Couldn't find anything else in neutron logs as well Just to be sure, this isn't due to a NUMA scheduling issue by chance? I had this topic up a little bit ago, where it is possible to have Nova over-schedule a NUMA node when the flavor's parameters are not set correctly: http://lists.openstack.org/pipermail/openstack-discuss/2020-October/018045.html Eric From mrunge at matthias-runge.de Mon Nov 23 07:54:16 2020 From: mrunge at matthias-runge.de (Matthias Runge) Date: Mon, 23 Nov 2020 08:54:16 +0100 Subject: [telemetry] wallaby cycle planning session In-Reply-To: <0aa17d80-4bcd-eb66-41d6-5d9f0c5aa12b@debian.org> References: <0aa17d80-4bcd-eb66-41d6-5d9f0c5aa12b@debian.org> Message-ID: On 21/11/2020 02:38, Thomas Goirand wrote: > On 11/12/20 11:25 AM, Matthias Runge wrote: >> Hi there, >> >> one of the biggest challenges for the telemetry stack is currently the >> state of gnocchi, which is... undefined/unfortunate/under-contributed/...? >> >> Telemetry started long time ago as a simple component ceilometer, which >> was split into several components ceilometer, aodh, panko, and gnocchi. >> Julien wrote a story about this some time ago[1]. >> >> There has also been an attempt to fork gnocchi back to OpenStack[2]. >> >> To my knowledge, the original contributors are not paid anymore to work >> on gnocchi, and at the same time, moving on to do something else is >> totally fine. >> >> However, I am not sure if we (in OpenStack Telemetry) should or could >> maintain in addition to the rest of the telemetry stack a time-series >> database. I'd like to discuss this during a call. > > Matthias, > > I'm not sure I will have time to join the call. So hopefully, you > understand that I prefer email (also because I wont be able to > contribute to the project, so maybe joining the call would be overkill). > Could you list the alternatives? If not using Gnocchi, what other > backend would you use? As an operator I need a timeseries which is: > - free software > - HA > - able to scale > - packaged or packagable in my distro > Thomas, thank you for your email. Let me go into more details: since this requires some discussion, I am proposing to have a call instead of an email thread. The current stack uses gnocchi; you may be well aware of the back and forth around it. Also, I am not sure how much effort we can invest, or if that's feasible. I totally agree, we'd want a free software (not some open core or so) and also a scalable solution (you may have heard some load issues with old ceilometer or gnocchi before). Another solution may be to split use cases and to use gnocchi with an in-memory store for short lived telemetry data and a different backend for long time store, for example for billing data etc. If we stop providing the gnocchi API (or don't bring the old ceilometer API back), we'll also cut off applications currently using that API. All that requires some coordination. Does that explain my preference for a call? > I don't know any time series db (apart from Gnocchi) that check all the > bullets above. Do you? Personally, I wouldn't check gnocchi on the scalable bullet. (I'm eager to hear your success stories, that would make things much easier). Or let me rephrase this: it seems to be easier to achieve ingesting much more metrics per time interval e.g by using prometheus and at the same time using less hardware resources. Matthias > > On 11/20/20 3:48 PM, Matthias Runge wrote: >> If it works for you, let's use this bluejeans channel[4] for the >> discussion. > > Gosh, reading that you'd be using bluejeans, then definitively, I will > not be able to join the call... :/ > > Cheers, > > Thomas Goirand (zigo) > From mrunge at matthias-runge.de Mon Nov 23 08:07:51 2020 From: mrunge at matthias-runge.de (Matthias Runge) Date: Mon, 23 Nov 2020 09:07:51 +0100 Subject: [telemetry] wallaby cycle planning session In-Reply-To: <20201121142639.2bmljzki4pjoye27@yuggoth.org> References: <0aa17d80-4bcd-eb66-41d6-5d9f0c5aa12b@debian.org> <20201121142639.2bmljzki4pjoye27@yuggoth.org> Message-ID: <70c7a2ab-70e3-e0f7-723d-eafb619a893b@matthias-runge.de> On 21/11/2020 15:26, Jeremy Stanley wrote: > On 2020-11-21 02:38:54 +0100 (+0100), Thomas Goirand wrote: > [...] >> Gosh, reading that you'd be using bluejeans, then definitively, I will >> not be able to join the call... :/ > > If it helps, I've been able to join Bluejeans calls with just > Firefox (the version in debian/unstable at least), no proprietary > browser extension or separate client needed. It may not be ideal, > but it's worked for me in the past anyway. > Thanks again for raising this. Tbh, I was expecting to hear exactly that concern from you, but I couldn't find a "better" solution for now. While I know bluejeans itself is not open source, it's a hosted solution. But it doesn't require you to install any additional software or an "app". It worked with old firefox versions and it does with newer as well. You can also dial in with local numbers, if you don't want or can not use a computer. A real alternative may be big blue button, or senfcall.de; I haven't tested that in world-wide communications so far; my personal experience with jitsi calls from the same area was that it scaled up to a few participants. Currently, I don't know how many people will join the call. On a side note, is anyone aware of a service like "doodle", but without privacy issues? (I was expecting protest about using doodle as well). Matthias From tobias.urdin at binero.com Mon Nov 23 08:30:12 2020 From: tobias.urdin at binero.com (Tobias Urdin) Date: Mon, 23 Nov 2020 08:30:12 +0000 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: <6feed46a-c1b8-74ac-f59a-d45b2bfefd67@debian.org> References: , <6feed46a-c1b8-74ac-f59a-d45b2bfefd67@debian.org> Message-ID: <4b2eb7c4b98846628e1d1e8e389ccc5f@binero.com> Hello, Just to clarify that this is already possible when using puppet-nova, it's up to the deployment to make sure the database parameters for the classes is set. We've been running without database credentials in nova.conf on our compute nodes for years. Best regards Tobias ________________________________ From: Thomas Goirand Sent: Saturday, November 21, 2020 2:47:23 AM To: openstack maillist Subject: Re: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service On 11/18/20 8:24 PM, Dan Smith wrote: > which things are > _not_allowed_ to be set for a service (such as db credentials on the > compute). I still don't understand why this is forbidden. Sure, I understand what people wrote: that it is a security problem. Can't nova-compute just *ignore* the db credentials, and then everyone is done with it, and moves on? That's a much more easy way to handle this problem, IMO. Cheers, Thomas Goirand (zigo) -------------- next part -------------- An HTML attachment was scrubbed... URL: From zigo at debian.org Mon Nov 23 08:30:23 2020 From: zigo at debian.org (Thomas Goirand) Date: Mon, 23 Nov 2020 09:30:23 +0100 Subject: [telemetry] wallaby cycle planning session In-Reply-To: References: <0aa17d80-4bcd-eb66-41d6-5d9f0c5aa12b@debian.org> Message-ID: <5ed61713-858a-c6b3-5c9a-6d7dbe366954@debian.org> On 11/23/20 8:54 AM, Matthias Runge wrote: > Personally, I wouldn't check gnocchi on the scalable bullet. (I'm eager > to hear your success stories, that would make things much easier). Maybe you should read this: https://julien.danjou.info/gnocchi-4-performance/ Julien Danjou pretends Gnocchi is able to eat 100k record per second. I wouldn't bet on this, but that's probably enough for OpenStack. Though the biggest bottleneck is probably the notification bus, not the time series. I've heard that switching to kafka may help, but I'm really not a fan of this "solution" (which IMO isn't one, as Kafka brings its own set of problems). > Or let me rephrase this: it seems to be easier to achieve ingesting much > more metrics per time interval e.g by using prometheus and at the same > time using less hardware resources. Prometheus is already in Debian, and it's been there for the last 2 releases, so I'd be ok switching to it. However, you'd have to provide a migration path for those already using Gnocchi. Cheers, Thomas Goirand (zigo) From katonalala at gmail.com Mon Nov 23 09:28:09 2020 From: katonalala at gmail.com (Lajos Katona) Date: Mon, 23 Nov 2020 10:28:09 +0100 Subject: [all][healthcheck] In-Reply-To: References: Message-ID: Hi Erno, Thanks for the details, we will consider these. Regards Lajos Erno Kuvaja ezt írta (időpont: 2020. nov. 19., Cs, 18:14): > On Mon, Nov 16, 2020 at 10:21 AM Lajos Katona > wrote: > >> Hi, >> >> I send this mail out to summarize the discussion around Healthcheck API >> on Neutron PTG, and start a discussion how we can make this most valuable >> to the operators. >> >> On the Neutron PTG etherpad this topic is from L114: >> https://etherpad.opendev.org/p/neutron-wallaby-ptg . >> >> Background: oslo_middleware provides /healthcheck API path(see [1]), >> which can be used to poll by services like haproxy, and gives a plugin >> mechanism to add some more complicated checks, which can be switched on/off >> from config. >> >> The main questions: >> >> - Some common guidance what to present to the operators (if you check >> [2] and [3] in the comments there are really good questions/concerns) >> - Perhaps the API SIG has something about healtcheck, just I can't >> find it. >> - What to present with and without authentication (after checking >> again, I am not sure that it is possible to use authentication for the >> healthcheck) >> - A way forward can be to make it configurable with default to >> authenticated, and give the decision to the admin. >> - During the discussion the agreement was to separate the frontend >> health from the backend health and use direct indicators (like working db >> connectivity, and mq connectivity) instead of indirect indicators (like >> agents' health). >> >> Thanks in advance for the feedback. >> >> [1] >> https://docs.openstack.org/oslo.middleware/latest/reference/healthcheck_plugins.html >> [2] https://review.opendev.org/731396 >> [3] https://review.opendev.org/731554 >> >> Regards >> Lajos Katona (lajoskatona) >> >> > Hi Lajos, > > Bit of background in case you don't know. The oslo healthcheck middleware > is basically a combination of healthcheck middlewares carried within the > few projects ages ago bloated with the plugin framework I don't know of > anyone ever adopted using. The main point for those middlewares carried by > Swift(I think), Glance definitely and possibly some other projects before > osloing it was to give a place for load balancers to ping that does not > necessarily need to be logged every few seconds nor need to send the > excessive amounts of auth calls to keystone. If I recall correctly you can > already place it after keystone middleware if you prefer it being authed, I > don't know of anyone who does. > > Main purpose was to provide a way to detect if the service is not > responding or by using the disabled by file to bleed the inflight > connections for maintenance and drop them off the pool for new requests. I > think the original implementations were somewhere around 10-20 lines of > code and did just that job pretty reliably. > > Based on the plugin model, it's indeed very easy to leak information out > of that middleware and I think the plugins used need to take that into > account by careful design. I'd very much prefer not breaking the current > healthcheck and the very well stabilized API of it that has been in use for > years just because someone feels like it's a good idea to make leaky > plugins for it. Realizing that agent status might not be the right thing to > check is a good start, what you really want to have is indication is the > API service able to take in new requests or not, not if all permutations of > those requests will succeed on the current system status. Now there are > ways to chain multiples of these middlewares with different configs (with > different endpoints) and it might be worth considering having your plugins > with detailed failure conditions on the admin side that is not exposed to > the public and just very simple yei/nei on your public endpoint. Good luck > and I hope you find the correct balance of detail from the API and > usability. > > Best, > Erno "jokke" Kuvaja > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrunge at matthias-runge.de Mon Nov 23 09:30:33 2020 From: mrunge at matthias-runge.de (Matthias Runge) Date: Mon, 23 Nov 2020 10:30:33 +0100 Subject: [telemetry] wallaby cycle planning session In-Reply-To: <5ed61713-858a-c6b3-5c9a-6d7dbe366954@debian.org> References: <0aa17d80-4bcd-eb66-41d6-5d9f0c5aa12b@debian.org> <5ed61713-858a-c6b3-5c9a-6d7dbe366954@debian.org> Message-ID: <6ac683e1-e517-f98c-fcac-ee1b7e65eb2b@matthias-runge.de> On 23/11/2020 09:30, Thomas Goirand wrote: > On 11/23/20 8:54 AM, Matthias Runge wrote: >> Personally, I wouldn't check gnocchi on the scalable bullet. (I'm eager >> to hear your success stories, that would make things much easier). > > Maybe you should read this: > https://julien.danjou.info/gnocchi-4-performance/ > > Julien Danjou pretends Gnocchi is able to eat 100k record per second. I > wouldn't bet on this, but that's probably enough for OpenStack. > > Though the biggest bottleneck is probably the notification bus, not the > time series. I've heard that switching to kafka may help, but I'm really > not a fan of this "solution" (which IMO isn't one, as Kafka brings its > own set of problems). all of this should be discussed in the community and also decided on. If we pick gnocchi, then we should also buy in and help out. I know that friendly and fellow OpenStackers already contribute there, which doesn't mean that there could or should be more helping hands. >> Or let me rephrase this: it seems to be easier to achieve ingesting much >> more metrics per time interval e.g by using prometheus and at the same >> time using less hardware resources. > > Prometheus is already in Debian, and it's been there for the last 2 > releases, so I'd be ok switching to it. However, you'd have to provide a > migration path for those already using Gnocchi. > If there has to be a migration path, that's also up for discussion. We are not a service provider here, we are simply providing the software. And as for all software, a new release may also bring backwards incompatible changes.... Matthias From balazs.gibizer at est.tech Mon Nov 23 09:58:32 2020 From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer) Date: Mon, 23 Nov 2020 10:58:32 +0100 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] =?UTF-8?Q?Nova=0D=0A?= enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: Message-ID: On Thu, Nov 19, 2020 at 13:07, Balázs Gibizer wrote: > > > On Wed, Nov 18, 2020 at 11:24, Dan Smith wrote: >> >> That leads me to the first action item I think we need: >> >> ACTION 1: Make the wsgi app able to use something other than >> nova.conf >> >> All of our other services support a --config-file flag, and I don't >> see >> why we wouldn't allow this if it's necessary for deployments. In the >> pure API arrangement, it shouldn't really be necessary to change >> this, >> but clearly you may need to have multiple API workers with different >> configs, as is the case with metadata-per-cell, or even potentially >> some >> admin-focused private API endpoint. If it makes it easier for >> deployment >> tools to start the API workers with a specific config file, we should >> let them do that. You can already work around that hard-coded >> filename >> by setting OS_NOVA_CONFIG_DIR to something other than /etc/nova, but >> we >> shouldn't require them to create directories just to have separate >> configs. > > I will look into this change and propose patch a patch. Patch is up https://review.opendev.org/c/openstack/nova/+/763750 Cheers, gibi From balazs.gibizer at est.tech Mon Nov 23 10:09:35 2020 From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer) Date: Mon, 23 Nov 2020 11:09:35 +0100 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] =?UTF-8?Q?Nova=0D=0A?= enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: <519018307.59148790.1605865616072.JavaMail.zimbra@redhat.com> References: <519018307.59148790.1605865616072.JavaMail.zimbra@redhat.com> Message-ID: On Fri, Nov 20, 2020 at 04:46, Javier Pena wrote: >> > There was a long discussion on #openstack-nova today[3] around >> this >> > topic. So you can find more detailed reasoning there[3]. >> >> I just had a long voice chat with Ollie about this, trying to >> understand >> some of the challenges that still exist with some of the things >> we've >> discussed and the proposed forward steps. >> >> There are lots of things to clarify, I think, and we could honestly >> probably use a wider voice chat among the people that need to work >> on >> this. However, I'll try here. >> >> First off, I want to address the "do it like devstack" >> recommendation, >> and the subsequent suggestion of standardizing on something like a >> "nova-db.conf" file arrangement to keep the db credentials in one >> place. As Ollie has pointed out, devstack doesn't support all the >> various deployment arrangements (such as "one metadata api per >> cell") >> and thus doesn't have a prescription for how to arrange the config >> files >> in those scenarios. Specifically, an all-in-one deployment that >> includes >> multiple API services with different configs would currently have >> to hack >> around the hardcoded nova.conf file with the environment variable >> that >> allows them to specify a directory other than /etc/nova.conf. >> Devstack >> doesn't have to do this because it doesn't support that arrangement >> of >> services, but if it did, it would have to. >> >> So, I wanted to clarify something that came out of the IRC >> discussion, >> which is "do it like devstack". When we say that, or at least when >> *I* >> said it, we meant "have different config files for each service so >> that >> you can get the config elements appropriate for each service set >> correctly." That doesn't mean "nova-compute should point to >> /etc/nova/nova-cpu.conf because that's what devstack does". >> Especially >> in a containerized setup, I would expect everything to use >> /etc/nova/nova.conf, since those are namespaced per-service because >> of >> the containerization. Further, just because devstack doesn't run a >> metadata per cell (or any other such optional arrangement), >> obviously >> that doesn't mean you can't. >> >> That leads me to the first action item I think we need: >> >> ACTION 1: Make the wsgi app able to use something other than >> nova.conf >> >> All of our other services support a --config-file flag, and I don't >> see >> why we wouldn't allow this if it's necessary for deployments. In the >> pure API arrangement, it shouldn't really be necessary to change >> this, >> but clearly you may need to have multiple API workers with different >> configs, as is the case with metadata-per-cell, or even potentially >> some >> admin-focused private API endpoint. If it makes it easier for >> deployment >> tools to start the API workers with a specific config file, we >> should >> let them do that. You can already work around that hard-coded >> filename >> by setting OS_NOVA_CONFIG_DIR to something other than /etc/nova, >> but we >> shouldn't require them to create directories just to have separate >> configs. >> >> The next item is related: >> >> ACTION 2: We need to document a minimal viable config for each >> service >> >> Ollie points out that, obviously, handing the deployer a config >> reference with 1.21 bajillion config options does not clearly >> indicate >> which services need which thing, and especially, which things are >> _not_allowed_ to be set for a service (such as db credentials on the >> compute). We can't feasibly audit every config option we have, but >> it >> would be very helpful to have a reference that shows what a >> completely >> minimal configuration for each service looks like. We could do that >> by >> tagging services per config options (which I suggested earlier, and >> would still be good) but I think maybe a standalone document would >> be >> easier for people to follow. >> >> Now, on to the question about the hard-fail patch for compute: >> >> https://review.opendev.org/#/c/762176/ >> >> The Nova devs have wanted people to _not_ have db credentials in the >> config file that nova-compute can see for a "Very Long Time." We >> have >> even made some assumptions in the code that rely on these >> credentials >> being not set on the compute, which is at least partially why we're >> having this conversation (again) now. >> >> Despite the fact that nobody *should* be setting these credentials >> in >> their config file, we know that at in least some circumstances, they >> are. TripleO is setting them (always I think?) because puppet-nova >> does >> that. OSA has said that they're setting them somewhat incidentally >> when >> they do all-in-one deployments. The latter is unlikely to affect any >> real deployments, but the former definitely _will_, and anyone else >> that >> isn't present in this discussion may be including credentials >> unnecessarily, which we will break when we merge that patch. Thus, I >> think that, even though it feels long overdue for devs, the most >> prudent >> and cautious approach will be to: >> >> ACTION 3: Not merge that hard fail until X >> >> We have the warning, we have the reno. We expect that the deployment >> tools will be working to eliminate the credentials for the compute >> config, but merging that will make it an emergency for them. We've >> waited years at this point, we can wait one more cycle for safety. >> As >> Ollie pointed out, we've not been super clear about messaging this, >> despite it being a well-worn assumption amongst the developers for a >> long time. >> >> To aid in smoking out any of the jobs or configs that deployment >> tools >> may still have which will break when we merge that patch, we should >> also >> consider: >> >> ACTION 4: A workaround flag to opt-in to the strict checking >> >> Basically, this would be a one or two-cycle workaround, which when >> enabled, would opt-in to the (above) behavior of causing compute to >> fail >> on startup if db credentials are present. This would allow the >> deployment tool maintainers, as well as people responsible for CI >> jobs >> to smoke test the new behavior early, before we merge it and cause >> an >> emergency for them. We can set this as on by default in our devstack >> jobs to signal that it is good with the new behavior, and also >> encourage >> the other deployment projects to set it as well once they're >> generating >> clean configs for their nova-computes. Once we merge the patch to >> actually fail all the time, we can remove this workaround config, >> according to the original intent of the workarounds group, that >> those >> flags are short-lived. >> >> We could do this by altering gibi's patch to only fail if the >> workaround >> is enabled, and then follow up in X by removing the workaround >> check. >> >> So, I know that was a lot of words, but I think if we can agree to >> the >> above four items, we'll have a path forward that doesn't overly >> burden >> any one specific group while still allowing us to chart a path to >> getting where we want to be. >> >> I think we need acks from a bunch of groups, probably at least: >> >> - Nova (gibi, stephenfin) >> - TripleO (owalsh) >> - Debian (zigo) >> - Kolla (yoctozepto) >> - OSA (noonedeadpunk) >> - rdo-ci (jpena) >> - puppet-nova (tkajinam) >> >> Are people okay with these action items? >> > > Hi Dan, > > Thanks for the detailed proposal. It looks good to me. > > Echoing Takashi's concerns, it would be great if action 2 could also > include generating some separate oslo-config-generator configuration > files. That would help distributions generate different nova-*.conf > files, and then deployment projects could follow. We quickly touch this topic before on IRC and it is considered a huge work to tag each nova config option with the service it uses. So I would not think it will happen without figuring out a gradual approach and having people signing up to help. Cheers, gibi > > Regards, > Javier > >> --Dan >> >> > > From pbasaras at gmail.com Mon Nov 23 10:11:55 2020 From: pbasaras at gmail.com (Pavlos Basaras) Date: Mon, 23 Nov 2020 12:11:55 +0200 Subject: [neutron] Cannot deploy instance in provider network openstack Ussuri -- network fails Message-ID: Hello, i am new to Openstack. I have followed the instructions from https://docs.openstack.org/install-guide/ to install openstack Ussuri where i use a controller node and a compute node (i can ping each other and access the internet from both nodes through the mgmt iface). I use ubuntu 18.04 for all components. I have configured the network option 2, seems to work fine: openstack network agent list +--------------------------------------+--------------------+------------+-------------------+-------+-------+---------------------------+ | ID | Agent Type | Host | Availability Zone | Alive | State | Binary | +--------------------------------------+--------------------+------------+-------------------+-------+-------+---------------------------+ | 2d8c3a89-32c4-4b97-aa4f-ca19db53b24f | L3 agent | controller | nova | :-) | UP | neutron-l3-agent | | 413cd13d-88d7-45ce-8b2e-26fdb265740f | Metadata agent | controller | None | :-) | UP | neutron-metadata-agent | | 42f57bee-63b3-44e6-9392-939ece98719d | Linux bridge agent | compute | None | :-) | UP | neutron-linuxbridge-agent | | 4a787a09-04aa-4350-bd32-0c0177ed06a1 | DHCP agent | controller | nova | :-) | UP | neutron-dhcp-agent | | fdafc337-7581-4ecd-b175-810713a25e1f | Linux bridge agent | controller | None | :-) | UP | neutron-linuxbridge-agent | +--------------------------------------+--------------------+------------+-------------------+-------+-------+---------------------------+ If i try to bring up instances connected by an internal network, they are successfully deployed. When i use the provider network to bring up an instance with the command: openstack server create --flavor m1.tiny --image cirros034 --nic net-id=4463e4a7-3b06-46d9-b24f-3e2e7867ee96 --security-group=5cf380e5-efb3-48b3-b8e9-095b1ebd817d provider-instance the instance fails to be instantiated because the network cannot be deployed. I noticed two points from the neutron-linuxbridge-agent.log file at the compute node (the logs at the controller seem fine): 1) ERROR neutron.plugins.ml2.drivers.agent._common_agent pyroute2.netlink.exceptions.NetlinkError: (13, 'Permission denied') 2) INFO neutron.plugins.ml2.drivers.agent._common_agent [req-816902d4-6581-49c1-939a-6ea69b437c99 - - - - -] Linux bridge agent Agent out of sync with plugin! -- not sure if this one is a problem. One part that i am not sure is the following configuration since i am on ubuntu 18 and not ubuntu 16: # The provider network interface auto INTERFACE_NAME iface INTERFACE_NAME inet manual up ip link set dev $IFACE up down ip link set dev $IFACE down I did not include this part in my file since its ubuntu 18, and netplan does not have an equivalent (i think) option. I have this netplan config enp0s8: --> mgmt dhcp4: false addresses: [10.0.0.31/24] gateway4: 10.0.0.1 nameservers: addresses: [8.8.8.8, 8.8.4.4] enp0s9: --> provider dhcp4: false any advice? all the best, Pavlos Basaras -------------- next part -------------- An HTML attachment was scrubbed... URL: From zigo at debian.org Mon Nov 23 10:18:25 2020 From: zigo at debian.org (Thomas Goirand) Date: Mon, 23 Nov 2020 11:18:25 +0100 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: <4b2eb7c4b98846628e1d1e8e389ccc5f@binero.com> References: <6feed46a-c1b8-74ac-f59a-d45b2bfefd67@debian.org> <4b2eb7c4b98846628e1d1e8e389ccc5f@binero.com> Message-ID: <0a5ae0ef-463c-3691-60a2-fc6d85520c23@debian.org> On 11/23/20 9:30 AM, Tobias Urdin wrote: > Hello, > > > Just to clarify that this is already possible when using > puppet-nova, it's up to the deployment to > > make sure the database parameters for the classes is set. > > > We've been running without database credentials in nova.conf on our > compute nodes for years. > > > Best regards > > Tobias Hi Tobias, That's not what I'm suggesting. I'm suggesting that nova-compute code from upstream simply ignores completely anything related to db connection, so we're done with the topic. That is, if nova-compute process having access to the db is the issue we're trying to fix. Or is it that the security problem is having the db credentials written in a file on the compute node? If so, isn't having hacked root (or nova) access to a compute node already game-over? What are we trying to secure here? If that's what I'm thinking (ie: some VM code to escape from guest, and potentially the hacker can gain access to the db), then IMO that's not the way to enforce things. It's not the role of upstream Nova to do this apart from a well enough written documentation. Cheers, Thomas Goirand (zigo) From zigo at debian.org Mon Nov 23 10:22:07 2020 From: zigo at debian.org (Thomas Goirand) Date: Mon, 23 Nov 2020 11:22:07 +0100 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: <55f9722d-dc81-c984-1991-30351d6231e0@debian.org> References: <4211161605171577@mail.yandex.ru> <5971221605688542@mail.yandex.ru> <661281605711741@mail.yandex.ru> <55f9722d-dc81-c984-1991-30351d6231e0@debian.org> Message-ID: <0f02050a-946a-c2ef-3bcd-c91d67c2390a@debian.org> On 11/21/20 2:40 AM, Thomas Goirand wrote: > On 11/18/20 4:06 PM, Dmitriy Rabotyagov wrote: >> Well, at least that does not work for nova then... uwsgi output and conf >> [1], journalctl logs [2] >>   >>   >> [1] http://paste.openstack.org/show/800158/ >> [2] http://paste.openstack.org/show/800159/ > > I can assure you that what I wrote works. Look at the Neutron packages > in Debian if you want to make sure of that... :) > > Thomas Goirand (zigo) > Hi, See what' Gibi wrote in this thread, and his patch here: https://review.opendev.org/c/openstack/nova/+/763750 The issue isn't uwsgi and the --pyargs, but nova-api not taking args into account, which is now addressed by the above patch. Cheers, Thomas Goirand (zigo) From balazs.gibizer at est.tech Mon Nov 23 10:31:05 2020 From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer) Date: Mon, 23 Nov 2020 11:31:05 +0100 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] =?UTF-8?Q?Nova=0D=0A?= enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: <6feed46a-c1b8-74ac-f59a-d45b2bfefd67@debian.org> References: <6feed46a-c1b8-74ac-f59a-d45b2bfefd67@debian.org> Message-ID: On Sat, Nov 21, 2020 at 02:47, Thomas Goirand wrote: > On 11/18/20 8:24 PM, Dan Smith wrote: >> which things are >> _not_allowed_ to be set for a service (such as db credentials on the >> compute). > > I still don't understand why this is forbidden. > > Sure, I understand what people wrote: that it is a security problem. > > Can't nova-compute just *ignore* the db credentials, and then everyone > is done with it, and moves on? That's a much more easy way to handle > this problem, IMO. It is still a security problem if nova-compute ignores the config as the config still exists on the hypervisor node (in some deployment scenarios) There are two existing technical reasons too: * Nova uses the [api_database]connection config to determine if the client of the compute RPC runs on the top level (i.e. super conductor) or locally in a cell (i.e. cell conductor or a nova-compute). [1] * The fairly recent change[2] that prevents older that N-1 services to start also depends on the [api_database]connection config to determine the scope (global vs. cell local) of the query that gathers the current service level of the cluster. I don't think that the [api_database]connection dependency can be removed from the super-conductor and cell-conductor differentiation perspective. From the nova-compute perspective we might be able to replace the [api_database]connection dependency with some hack. E.g to put the service name to the global CONF object at the start of the service binary and depend on that instead of other part of the config. But I feel pretty bad about this hack. Cheers, gibi [1] https://github.com/openstack/nova/blob/e16800cc0aebf1174c5c0b6c4b043b09622524e9/nova/compute/rpcapi.py#L441 [2] https://github.com/openstack/nova/blob/e16800cc0aebf1174c5c0b6c4b043b09622524e9/nova/utils.py#L1064 > > Cheers, > > Thomas Goirand (zigo) > From mark at stackhpc.com Mon Nov 23 10:33:42 2020 From: mark at stackhpc.com (Mark Goddard) Date: Mon, 23 Nov 2020 10:33:42 +0000 Subject: [kolla][ptg] Kolla Wallaby priorities In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 at 15:06, Mark Goddard wrote: > > On Fri, 30 Oct 2020 at 20:26, Mark Goddard wrote: > > > > Hi, > > > > Thanks to everyone who attended the Kolla PTG sessions, we covered a > > lot of ground. The Etherpad is available at [1]. I wrote an email [2] > > summarising the discussions. I have moved candidate work items across > > to a second Etherpad [2] for voting on. > > > > Now is the time to vote! Please add your name against a maximum of 12 > > items across the 3 deliverables (kolla, kolla-ansible, kayobe) in the > > priorities [2] Etherpad. Anyone in the community is welcome to vote. > > > > [1] https://etherpad.opendev.org/p/kolla-wallaby-ptg > > [2] http://lists.openstack.org/pipermail/openstack-discuss/2020-October/018445.html > > [3] https://etherpad.opendev.org/p/kolla-wallaby-priorities > > I'll close the poll at the end of this week. Please get your votes in > before then. Voting is now closed. I have added up the votes, and ordered the priorities on the Whiteboard [1]. Thank you to everyone who voted. Do not despair if your feature is not high on the list, or on it at all - this is simply a guide for contributors to help steer the direction of the project. # General * High level documentation, eg. examples of networking config, diagrams, justification of use of containers, not k8s etc. (8 votes) * Ability to run CI jobs locally (without Zuul, but possibly with Ansible) (5 votes) # Kolla * Infra images (4 votes) https://blueprints.launchpad.net/kolla/+spec/infra-images * Image tiering (3 votes) Avoid breakage of non-core images blocking publishing of all others * Integrate support for pull-retag-push (3 votes) https://storyboard.openstack.org/#!/story/2007731 (original kayobe story) * Build, test, promote CI pipeline (3 votes) Build images, test them, promote for general availability # Kolla Ansible * HAProxy hitless reload (8 votes) * TLS in other services: (7 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/mariadb-ssl-support https://blueprints.launchpad.net/kolla-ansible/+spec/memcached-ssl-support * Let's Encrypt integration - container running certbot, triggers certificate distribution (6 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/letsencrypt-https * Implement TLS Backend for all remaining API services with externally exposed API (5 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/add-ssl-internal-network * Modernise the old skool Swift role (5 votes) * Container health checks (continued) (4 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/container-health-check * Upgrade checkers (3 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/upgrade-checkers * More fine grained skipping of tasks, e.g. allow to skip service registration (3 votes) * Support to identity federation (OpenID Connect) configurations in Keystone and Horizon via Kolla-ansible (3 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/add-openid-support * Replace use of Docker with Podman (3 votes) * Support extensions to deployment (3 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/deploy-extensions * Performance improvements (3 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/performance-improvements * Octavia - automated health manager network interface management (3 votes) https://review.opendev.org/755589 * Masakari hostmonitor support (2 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/masakari-hostmonitor * Native fluentd logging (2 votes) * Day 2 ops tools (restart containers, upgrade Docker, prune DBs…) (2 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/docker-upgrade-reconfigure-command * Designate - automated zone creation (1 vote) * Node removal (decommission) (1 vote) https://blueprints.launchpad.net/kolla-ansible/+spec/remove-node * Capture docker logs (1 vote) https://blueprints.launchpad.net/kolla-ansible/+spec/capture-docker-logs * DNS-based endpoint naming (1 vote) mini spec: https://review.opendev.org/759706 # Kayobe * Support multiple environments from a single kayobe configuration (4 votes) * Document configuration walk through (4 votes) https://storyboard.openstack.org/#!/story/2004360 * Offline configuration generation (3 votes) * Next generation discovery & network configuration (2 votes) https://storyboard.openstack.org/#!/story/2004295 * Replace bifrost with kolla-ansible for seed services (2 votes) https://storyboard.openstack.org/#!/story/2004293 * Switch to NetworkManager (1 vote) * Strip out Grafana post configure functionality and move it to Kolla-Ansible (1 vote) * Support external custom playbooks, roles and plugins via Ansible collections (1 vote) * Hashivault integration (1 vote) * Support for multiple deploy image types on overcloud nodes (0 votes) https://storyboard.openstack.org/#!/story/2002098 [1] https://etherpad.opendev.org/p/KollaWhiteBoard > > > > > Thanks, > > Mark From mark at stackhpc.com Mon Nov 23 10:37:04 2020 From: mark at stackhpc.com (Mark Goddard) Date: Mon, 23 Nov 2020 10:37:04 +0000 Subject: [kolla][ptg] Kolla Wallaby priorities In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 at 10:33, Mark Goddard wrote: > > On Wed, 18 Nov 2020 at 15:06, Mark Goddard wrote: > > > > On Fri, 30 Oct 2020 at 20:26, Mark Goddard wrote: > > > > > > Hi, > > > > > > Thanks to everyone who attended the Kolla PTG sessions, we covered a > > > lot of ground. The Etherpad is available at [1]. I wrote an email [2] > > > summarising the discussions. I have moved candidate work items across > > > to a second Etherpad [2] for voting on. > > > > > > Now is the time to vote! Please add your name against a maximum of 12 > > > items across the 3 deliverables (kolla, kolla-ansible, kayobe) in the > > > priorities [2] Etherpad. Anyone in the community is welcome to vote. > > > > > > [1] https://etherpad.opendev.org/p/kolla-wallaby-ptg > > > [2] http://lists.openstack.org/pipermail/openstack-discuss/2020-October/018445.html > > > [3] https://etherpad.opendev.org/p/kolla-wallaby-priorities > > > > I'll close the poll at the end of this week. Please get your votes in > > before then. > > Voting is now closed. I have added up the votes, and ordered the > priorities on the Whiteboard [1]. Thank you to everyone who voted. Do > not despair if your feature is not high on the list, or on it at all - > this is simply a guide for contributors to help steer the direction of > the project. > > # General > > * High level documentation, eg. examples of networking config, > diagrams, justification of use of containers, not k8s etc. (8 votes) > > * Ability to run CI jobs locally (without Zuul, but possibly with > Ansible) (5 votes) > > # Kolla > > * Infra images (4 votes) > https://blueprints.launchpad.net/kolla/+spec/infra-images > > * Image tiering (3 votes) > Avoid breakage of non-core images blocking publishing of all others > > * Integrate support for pull-retag-push (3 votes) > https://storyboard.openstack.org/#!/story/2007731 (original kayobe story) > > * Build, test, promote CI pipeline (3 votes) > Build images, test them, promote for general availability > > # Kolla Ansible > > * HAProxy hitless reload (8 votes) > > * TLS in other services: (7 votes) > https://blueprints.launchpad.net/kolla-ansible/+spec/mariadb-ssl-support > https://blueprints.launchpad.net/kolla-ansible/+spec/memcached-ssl-support > > * Let's Encrypt integration - container running certbot, triggers > certificate distribution (6 votes) > https://blueprints.launchpad.net/kolla-ansible/+spec/letsencrypt-https > > * Implement TLS Backend for all remaining API services with externally > exposed API (5 votes) > https://blueprints.launchpad.net/kolla-ansible/+spec/add-ssl-internal-network > > * Modernise the old skool Swift role (5 votes) > > * Container health checks (continued) (4 votes) > https://blueprints.launchpad.net/kolla-ansible/+spec/container-health-check > > * Upgrade checkers (3 votes) > https://blueprints.launchpad.net/kolla-ansible/+spec/upgrade-checkers > > * More fine grained skipping of tasks, e.g. allow to skip service > registration (3 votes) > > * Support to identity federation (OpenID Connect) configurations in > Keystone and Horizon via Kolla-ansible (3 votes) > https://blueprints.launchpad.net/kolla-ansible/+spec/add-openid-support > > * Replace use of Docker with Podman (3 votes) > > * Support extensions to deployment (3 votes) > https://blueprints.launchpad.net/kolla-ansible/+spec/deploy-extensions > > * Performance improvements (3 votes) > https://blueprints.launchpad.net/kolla-ansible/+spec/performance-improvements > > * Octavia - automated health manager network interface management (3 votes) > https://review.opendev.org/755589 > > * Masakari hostmonitor support (2 votes) > https://blueprints.launchpad.net/kolla-ansible/+spec/masakari-hostmonitor > > * Native fluentd logging (2 votes) > > * Day 2 ops tools (restart containers, upgrade Docker, prune DBs…) (2 votes) > https://blueprints.launchpad.net/kolla-ansible/+spec/docker-upgrade-reconfigure-command > > * Designate - automated zone creation (1 vote) > > * Node removal (decommission) (1 vote) > https://blueprints.launchpad.net/kolla-ansible/+spec/remove-node > > * Capture docker logs (1 vote) > https://blueprints.launchpad.net/kolla-ansible/+spec/capture-docker-logs > > * DNS-based endpoint naming (1 vote) > mini spec: https://review.opendev.org/759706 > > # Kayobe > > * Support multiple environments from a single kayobe configuration (4 votes) > > * Document configuration walk through (4 votes) > https://storyboard.openstack.org/#!/story/2004360 > > * Offline configuration generation (3 votes) > > * Next generation discovery & network configuration (2 votes) > https://storyboard.openstack.org/#!/story/2004295 > > * Replace bifrost with kolla-ansible for seed services (2 votes) > https://storyboard.openstack.org/#!/story/2004293 > > * Switch to NetworkManager (1 vote) > > * Strip out Grafana post configure functionality and move it to > Kolla-Ansible (1 vote) > > * Support external custom playbooks, roles and plugins via Ansible > collections (1 vote) > > * Hashivault integration (1 vote) > > * Support for multiple deploy image types on overcloud nodes (0 votes) > https://storyboard.openstack.org/#!/story/2002098 > > [1] https://etherpad.opendev.org/p/KollaWhiteBoard Of course, if there is something you would like to work on or be involved with, please add your name on the whiteboard. > > > > > > > > > Thanks, > > > Mark From balazs.gibizer at est.tech Mon Nov 23 10:42:07 2020 From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer) Date: Mon, 23 Nov 2020 11:42:07 +0100 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] =?UTF-8?Q?Nova=0D=0A?= enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: <0a5ae0ef-463c-3691-60a2-fc6d85520c23@debian.org> References: <6feed46a-c1b8-74ac-f59a-d45b2bfefd67@debian.org> <4b2eb7c4b98846628e1d1e8e389ccc5f@binero.com> <0a5ae0ef-463c-3691-60a2-fc6d85520c23@debian.org> Message-ID: <7EW8KQ.UNB9NASIF2Q11@est.tech> On Mon, Nov 23, 2020 at 11:18, Thomas Goirand wrote: > On 11/23/20 9:30 AM, Tobias Urdin wrote: >> Hello, >> >> >> Just to clarify that this is already possible when using >> puppet-nova, it's up to the deployment to >> >> make sure the database parameters for the classes is set. >> >> >> We've been running without database credentials in nova.conf on our >> compute nodes for years. >> >> >> Best regards >> >> Tobias > > Hi Tobias, > > That's not what I'm suggesting. > > I'm suggesting that nova-compute code from upstream simply ignores > completely anything related to db connection, so we're done with the > topic. That is, if nova-compute process having access to the db is the > issue we're trying to fix. > > Or is it that the security problem is having the db credentials > written > in a file on the compute node? If so, isn't having hacked root (or > nova) > access to a compute node already game-over? > > What are we trying to secure here? If that's what I'm thinking (ie: > some > VM code to escape from guest, and potentially the hacker can gain > access > to the db), then IMO that's not the way to enforce things. It's not > the > role of upstream Nova to do this apart from a well enough written > documentation. I always understood this as having a goal to limit the attack surface. So if a VM escapes out of the sandbox and access the hypervisor then limit how may other services get compromised outside of the compromised compute host. Cheers, gibi > > Cheers, > > Thomas Goirand (zigo) > From balazs.gibizer at est.tech Mon Nov 23 10:48:15 2020 From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer) Date: Mon, 23 Nov 2020 11:48:15 +0100 Subject: [nova] heads up about the limitations of the new gerrit Message-ID: Hi, We have the new shiny gerrit. But please be aware the limitations[1]. I want to highlight one. The launchpad - gerrit integration does not work so the bluperints and bugs are not updated in launchpad based on the changes in gerrit. So please manually update launchpad. cheers, gibi [1] https://etherpad.opendev.org/p/gerrit-3.2-post-upgrade-notes From hberaud at redhat.com Mon Nov 23 11:49:56 2020 From: hberaud at redhat.com (Herve Beraud) Date: Mon, 23 Nov 2020 12:49:56 +0100 Subject: [release][infra] SSH key error - RedFlag stop approving Message-ID: Hello, We are facing SSH issues on our release jobs [1][2]. Indeed, our release account failed to connect to gerrit through SSH [2]. The ID seems to be recognized when we try it. So that would probably mean we have a stale host key on the machine the script is running on . We suppose that the issue could be a side effect of the gerrit upgrade, we updated the etherpad to inform the infra team [3] @release managers: We should stop approving, so, please hold all our unmerged patches while this incident isn't solved. Thanks for your reading, [1] http://lists.openstack.org/pipermail/release-job-failures/2020-November/001487.html[2] Example of faced error: ``` ssh://release at review.opendev.org:29418/openstack/python-senlinclient.git did not work. Description: Host key verification failed. Could not read from remote repository ``` [3] https://etherpad.opendev.org/p/gerrit-3.2-post-upgrade-notes -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Mon Nov 23 11:52:37 2020 From: skaplons at redhat.com (Slawek Kaplonski) Date: Mon, 23 Nov 2020 12:52:37 +0100 Subject: [neutron] Cannot deploy instance in provider network openstack Ussuri -- network fails In-Reply-To: References: Message-ID: <20201123115237.moahcpvoreslx4wk@p1.localdomain> Hi, On Mon, Nov 23, 2020 at 12:11:55PM +0200, Pavlos Basaras wrote: > Hello, > > i am new to Openstack. > > I have followed the instructions from > https://docs.openstack.org/install-guide/ to install openstack Ussuri where > i use a controller node and a compute node (i can ping each other and > access the internet from both nodes through the mgmt iface). > > I use ubuntu 18.04 for all components. > > I have configured the network option 2, seems to work fine: > > openstack network agent list > +--------------------------------------+--------------------+------------+-------------------+-------+-------+---------------------------+ > | ID | Agent Type | Host | > Availability Zone | Alive | State | Binary | > +--------------------------------------+--------------------+------------+-------------------+-------+-------+---------------------------+ > | 2d8c3a89-32c4-4b97-aa4f-ca19db53b24f | L3 agent | controller | > nova | :-) | UP | neutron-l3-agent | > | 413cd13d-88d7-45ce-8b2e-26fdb265740f | Metadata agent | controller | > None | :-) | UP | neutron-metadata-agent | > | 42f57bee-63b3-44e6-9392-939ece98719d | Linux bridge agent | compute | > None | :-) | UP | neutron-linuxbridge-agent | > | 4a787a09-04aa-4350-bd32-0c0177ed06a1 | DHCP agent | controller | > nova | :-) | UP | neutron-dhcp-agent | > | fdafc337-7581-4ecd-b175-810713a25e1f | Linux bridge agent | controller | > None | :-) | UP | neutron-linuxbridge-agent | > +--------------------------------------+--------------------+------------+-------------------+-------+-------+---------------------------+ > > If i try to bring up instances connected by an internal network, they are > successfully deployed. > > When i use the provider network to bring up an instance with the command: > openstack server create --flavor m1.tiny --image cirros034 --nic > net-id=4463e4a7-3b06-46d9-b24f-3e2e7867ee96 > --security-group=5cf380e5-efb3-48b3-b8e9-095b1ebd817d provider-instance > > the instance fails to be instantiated because the network cannot be > deployed. > > I noticed two points from the neutron-linuxbridge-agent.log file at the > compute node (the logs at the controller seem fine): > > 1) ERROR neutron.plugins.ml2.drivers.agent._common_agent > pyroute2.netlink.exceptions.NetlinkError: (13, 'Permission denied') This sounds like maybe some issue with usage of sudo by user which runs neutron-linuxbridge-agent. Is it configured properly? > 2) INFO neutron.plugins.ml2.drivers.agent._common_agent > [req-816902d4-6581-49c1-939a-6ea69b437c99 - - - - -] Linux bridge agent > Agent out of sync with plugin! -- not sure if this one is a problem. This is probably just a result of above error. But to be sure I would need to see whole log. If You will still have such issue, please open LP bug and attach Your logs there. In such way it should be maybe easier to investigate what is going on there. In Ussuri we are running CI job neutron-tempest-plugin-scenario-linuxbridge which deploys neutron-linuxbridge-agent and all works fine there. You can check that e.g. on https://zuul.opendev.org/t/openstack/build/441182cb87fd47daa34d5018fc2eb9ab > > One part that i am not sure is the following configuration since i am on > ubuntu 18 and not ubuntu 16: > > # The provider network interface > auto INTERFACE_NAME > iface INTERFACE_NAME inet manual > up ip link set dev $IFACE up > down ip link set dev $IFACE down > > I did not include this part in my file since its ubuntu 18, and netplan > does not have an equivalent (i think) option. I have this netplan config > > enp0s8: --> mgmt > dhcp4: false > addresses: [10.0.0.31/24] > gateway4: 10.0.0.1 > nameservers: > addresses: [8.8.8.8, 8.8.4.4] > enp0s9: --> provider > dhcp4: false > > > > any advice? > > all the best, > Pavlos Basaras -- Slawek Kaplonski Principal Software Engineer Red Hat From zigo at debian.org Mon Nov 23 12:21:14 2020 From: zigo at debian.org (Thomas Goirand) Date: Mon, 23 Nov 2020 13:21:14 +0100 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: <7EW8KQ.UNB9NASIF2Q11@est.tech> References: <6feed46a-c1b8-74ac-f59a-d45b2bfefd67@debian.org> <4b2eb7c4b98846628e1d1e8e389ccc5f@binero.com> <0a5ae0ef-463c-3691-60a2-fc6d85520c23@debian.org> <7EW8KQ.UNB9NASIF2Q11@est.tech> Message-ID: On 11/23/20 11:42 AM, Balázs Gibizer wrote: > > > On Mon, Nov 23, 2020 at 11:18, Thomas Goirand wrote: >> On 11/23/20 9:30 AM, Tobias Urdin wrote: >>>  Hello, >>> >>> >>>  Just to clarify that this is already possible when using >>>  puppet-nova, it's up to the deployment to >>> >>>  make sure the database parameters for the classes is set. >>> >>> >>>  We've been running without database credentials in nova.conf on our >>>  compute nodes for years. >>> >>> >>>  Best regards >>> >>>  Tobias >> >> Hi Tobias, >> >> That's not what I'm suggesting. >> >> I'm suggesting that nova-compute code from upstream simply ignores >> completely anything related to db connection, so we're done with the >> topic. That is, if nova-compute process having access to the db is the >> issue we're trying to fix. >> >> Or is it that the security problem is having the db credentials written >> in a file on the compute node? If so, isn't having hacked root (or nova) >> access to a compute node already game-over? >> >> What are we trying to secure here? If that's what I'm thinking (ie: some >> VM code to escape from guest, and potentially the hacker can gain access >> to the db), then IMO that's not the way to enforce things. It's not the >> role of upstream Nova to do this apart from a well enough written >> documentation. > > I always understood this as having a goal to limit the attack surface. > So if a VM escapes out of the sandbox and access the hypervisor then > limit how may other services get compromised outside of the compromised > compute host. > > Cheers, > gibi In general, I would agree with this. However, because of the way cold migrations are working, nova compute boxes are authenticated between each other through ssh. You'd be limiting access to the db, but someone with nova or root ssh access could destroy all compute nodes. So, like it or not, it's game-over anyways. If you want to fix things, make it so that Nova doesn't require such ssh authentication anymore, because that's more urgent, *THEN* we can revisit this topic. Cheers, Thomas Goirand (zigo) From balazs.gibizer at est.tech Mon Nov 23 12:31:00 2020 From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer) Date: Mon, 23 Nov 2020 13:31:00 +0100 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] =?UTF-8?Q?Nova=0D=0A?= enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: <6feed46a-c1b8-74ac-f59a-d45b2bfefd67@debian.org> <4b2eb7c4b98846628e1d1e8e389ccc5f@binero.com> <0a5ae0ef-463c-3691-60a2-fc6d85520c23@debian.org> <7EW8KQ.UNB9NASIF2Q11@est.tech> Message-ID: On Mon, Nov 23, 2020 at 13:21, Thomas Goirand wrote: > On 11/23/20 11:42 AM, Balázs Gibizer wrote: >> >> >> On Mon, Nov 23, 2020 at 11:18, Thomas Goirand >> wrote: >>> On 11/23/20 9:30 AM, Tobias Urdin wrote: >>>> Hello, >>>> >>>> >>>> Just to clarify that this is already possible when using >>>> puppet-nova, it's up to the deployment to >>>> >>>> make sure the database parameters for the classes is set. >>>> >>>> >>>> We've been running without database credentials in nova.conf on >>>> our >>>> compute nodes for years. >>>> >>>> >>>> Best regards >>>> >>>> Tobias >>> >>> Hi Tobias, >>> >>> That's not what I'm suggesting. >>> >>> I'm suggesting that nova-compute code from upstream simply ignores >>> completely anything related to db connection, so we're done with >>> the >>> topic. That is, if nova-compute process having access to the db is >>> the >>> issue we're trying to fix. >>> >>> Or is it that the security problem is having the db credentials >>> written >>> in a file on the compute node? If so, isn't having hacked root (or >>> nova) >>> access to a compute node already game-over? >>> >>> What are we trying to secure here? If that's what I'm thinking >>> (ie: some >>> VM code to escape from guest, and potentially the hacker can gain >>> access >>> to the db), then IMO that's not the way to enforce things. It's >>> not the >>> role of upstream Nova to do this apart from a well enough written >>> documentation. >> >> I always understood this as having a goal to limit the attack >> surface. >> So if a VM escapes out of the sandbox and access the hypervisor then >> limit how may other services get compromised outside of the >> compromised >> compute host. >> >> Cheers, >> gibi > > In general, I would agree with this. However, because of the way cold > migrations are working, nova compute boxes are authenticated between > each other through ssh. You'd be limiting access to the db, but > someone > with nova or root ssh access could destroy all compute nodes. So, like > it or not, it's game-over anyways. If you want to fix things, make it > so > that Nova doesn't require such ssh authentication anymore, because > that's more urgent, *THEN* we can revisit this topic. While I agree that we should do changes, if possible, to avoid the need of ssh between the computes, I don't agree that a compromised compute is a game over for the whole cloud. If the deployment is split up to cells, then the game over is limited to the cell the compromised compute is in. Cheers, gibi > > Cheers, > > Thomas Goirand (zigo) > From zigo at debian.org Mon Nov 23 12:47:39 2020 From: zigo at debian.org (Thomas Goirand) Date: Mon, 23 Nov 2020 13:47:39 +0100 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: <6feed46a-c1b8-74ac-f59a-d45b2bfefd67@debian.org> Message-ID: On 11/23/20 11:31 AM, Balázs Gibizer wrote: > It is still a security problem if nova-compute ignores the config as the > config still exists on the hypervisor node (in some deployment scenarios) Let's say we apply the patch you're proposing, and that nova-compute isn't loaded anymore with the db credentials, because it's on a separate file, and nova-compute doesn't load it. In such scenario, the /etc/nova/nova-db.conf could still be present with db credentials filled-in. So, the patch you're proposing is still not effective for wrong configuration of nova-compute hosts. > From the nova-compute perspective we might be able to > replace the [api_database]connection dependency with some hack. E.g to > put the service name to the global CONF object at the start of the > service binary and depend on that instead of other part of the config. > But I feel pretty bad about this hack. Because of the above, I very much think it'd be the best way to go, but I understand your point of view. Going to the /etc/nova/nova-db.conf and nova-api-db.conf thing is probably good anyways. As for the nova-conductor thing, I very much would prefer if we had a clean and explicit "superconductor=true" directive, with possibly some checks to display big warnings in the nova-conductor.log file in case of a wrong configuration. If we don't have that, then at least things must be extensively documented, because that's really not obvious what's going on. Cheers, Thomas Goirand (zigo) From aschultz at redhat.com Mon Nov 23 13:15:00 2020 From: aschultz at redhat.com (Alex Schultz) Date: Mon, 23 Nov 2020 06:15:00 -0700 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: <7EW8KQ.UNB9NASIF2Q11@est.tech> References: <6feed46a-c1b8-74ac-f59a-d45b2bfefd67@debian.org> <4b2eb7c4b98846628e1d1e8e389ccc5f@binero.com> <0a5ae0ef-463c-3691-60a2-fc6d85520c23@debian.org> <7EW8KQ.UNB9NASIF2Q11@est.tech> Message-ID: On Mon, Nov 23, 2020 at 3:47 AM Balázs Gibizer wrote: > > > > On Mon, Nov 23, 2020 at 11:18, Thomas Goirand wrote: > > On 11/23/20 9:30 AM, Tobias Urdin wrote: > >> Hello, > >> > >> > >> Just to clarify that this is already possible when using > >> puppet-nova, it's up to the deployment to > >> > >> make sure the database parameters for the classes is set. > >> > >> > >> We've been running without database credentials in nova.conf on our > >> compute nodes for years. > >> > >> > >> Best regards > >> > >> Tobias > > > > Hi Tobias, > > > > That's not what I'm suggesting. > > > > I'm suggesting that nova-compute code from upstream simply ignores > > completely anything related to db connection, so we're done with the > > topic. That is, if nova-compute process having access to the db is the > > issue we're trying to fix. > > > > Or is it that the security problem is having the db credentials > > written > > in a file on the compute node? If so, isn't having hacked root (or > > nova) > > access to a compute node already game-over? > > > > What are we trying to secure here? If that's what I'm thinking (ie: > > some > > VM code to escape from guest, and potentially the hacker can gain > > access > > to the db), then IMO that's not the way to enforce things. It's not > > the > > role of upstream Nova to do this apart from a well enough written > > documentation. > > I always understood this as having a goal to limit the attack surface. > So if a VM escapes out of the sandbox and access the hypervisor then > limit how may other services get compromised outside of the compromised > compute host. > I can agree with this in theory, however I don't think it's nova's responsibility to enforce this. IMHO a warning about this condition should be sufficient from a project standpoint. It's up to the operator to ensure this does not happen and not the project. The project can't foresee how the service is actually going to be deployed. In theory this is moot if the compute service is running on the same host as the api and not in something like a container. Escaping the service and having access to the host won't prevent the hacker from reading /etc/nova/nova-db.conf instead of /etc/nova/nova-compute.conf. > Cheers, > gibi > > > > > Cheers, > > > > Thomas Goirand (zigo) > > > > > From smooney at redhat.com Mon Nov 23 13:32:15 2020 From: smooney at redhat.com (Sean Mooney) Date: Mon, 23 Nov 2020 13:32:15 +0000 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: <6feed46a-c1b8-74ac-f59a-d45b2bfefd67@debian.org> <4b2eb7c4b98846628e1d1e8e389ccc5f@binero.com> <0a5ae0ef-463c-3691-60a2-fc6d85520c23@debian.org> <7EW8KQ.UNB9NASIF2Q11@est.tech> Message-ID: On Mon, 2020-11-23 at 06:15 -0700, Alex Schultz wrote: > On Mon, Nov 23, 2020 at 3:47 AM Balázs Gibizer wrote: > > > > > > > > On Mon, Nov 23, 2020 at 11:18, Thomas Goirand wrote: > > > On 11/23/20 9:30 AM, Tobias Urdin wrote: > > > >  Hello, > > > > > > > > > > > >  Just to clarify that this is already possible when using > > > >  puppet-nova, it's up to the deployment to > > > > > > > >  make sure the database parameters for the classes is set. > > > > > > > > > > > >  We've been running without database credentials in nova.conf on our > > > >  compute nodes for years. > > > > > > > > > > > >  Best regards > > > > > > > >  Tobias > > > > > > Hi Tobias, > > > > > > That's not what I'm suggesting. > > > > > > I'm suggesting that nova-compute code from upstream simply ignores > > > completely anything related to db connection, so we're done with the > > > topic. That is, if nova-compute process having access to the db is the > > > issue we're trying to fix. > > > > > > Or is it that the security problem is having the db credentials > > > written > > > in a file on the compute node? If so, isn't having hacked root (or > > > nova) > > > access to a compute node already game-over? > > > > > > What are we trying to secure here? If that's what I'm thinking (ie: > > > some > > > VM code to escape from guest, and potentially the hacker can gain > > > access > > > to the db), then IMO that's not the way to enforce things. It's not > > > the > > > role of upstream Nova to do this apart from a well enough written > > > documentation. > > > > I always understood this as having a goal to limit the attack surface. > > So if a VM escapes out of the sandbox and access the hypervisor then > > limit how may other services get compromised outside of the compromised > > compute host. > > > > I can agree with this in theory, however I don't think it's nova's > responsibility to enforce this. > nova need to enforce it as we use the absense or present of the db creads to know if common code is running in the compute agent or in controller services it activly breaks the nova compute agent if they are present. it is a bug to have the db cred in the set fo configs passed to nova-comptue and it has been for years. the fact it worked in some case does not change teh fact this was unsupported following a depercation cycle and activly depenedon in code after allowing operators, packagers and deployment tool maintianer years to ensure its no longer presnt. we could make this just a ERROR log without the hard fail but that would still not change the fact there is a bug in packages or deployment tools that should be fixed. > IMHO a warning about this condition > should be sufficient from a project standpoint. It's up to the > operator to ensure this does not happen and not the project. > that would be true if it was not something that the code relied on to function correctly. local condocutor mode was removed in grizzly, since then the db creds have been unsued in the compute node. when cells v2 was intoduced they were used to determin if we would check the version in the local cell or in all cells as aprt of rpc automatic upgarde level calulation. we now always to the auto discovery which cause it to break. > The > project can't foresee how the service is actually going to be > deployed. > we can define which methods of deployment we will support however. > In theory this is moot if the compute service is running on > the same host as the api and not in something like a container. not really we have expected nova-compute to not use nova.conf in an all in one deployment since rocky unless its in a container where it has a rendered version that only contains the section relevent to it. > Escaping the service and having access to the host won't prevent the > hacker from reading /etc/nova/nova-db.conf instead of > /etc/nova/nova-compute.conf. it wont but /etc/nova/nova-db.conf should not be on the compute node unless you are also deploying a service that will actully use it there. that is vald to do but it shoudl still not be bassed to the nova-comptue binary. > > Cheers, > > gibi > > > > > > > > Cheers, > > > > > > Thomas Goirand (zigo) > > > > > > > > > > > From aschultz at redhat.com Mon Nov 23 14:02:52 2020 From: aschultz at redhat.com (Alex Schultz) Date: Mon, 23 Nov 2020 07:02:52 -0700 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: <6feed46a-c1b8-74ac-f59a-d45b2bfefd67@debian.org> <4b2eb7c4b98846628e1d1e8e389ccc5f@binero.com> <0a5ae0ef-463c-3691-60a2-fc6d85520c23@debian.org> <7EW8KQ.UNB9NASIF2Q11@est.tech> Message-ID: On Mon, Nov 23, 2020 at 6:42 AM Sean Mooney wrote: > > On Mon, 2020-11-23 at 06:15 -0700, Alex Schultz wrote: > > On Mon, Nov 23, 2020 at 3:47 AM Balázs Gibizer wrote: > > > > > > > > > > > > On Mon, Nov 23, 2020 at 11:18, Thomas Goirand wrote: > > > > On 11/23/20 9:30 AM, Tobias Urdin wrote: > > > > > Hello, > > > > > > > > > > > > > > > Just to clarify that this is already possible when using > > > > > puppet-nova, it's up to the deployment to > > > > > > > > > > make sure the database parameters for the classes is set. > > > > > > > > > > > > > > > We've been running without database credentials in nova.conf on our > > > > > compute nodes for years. > > > > > > > > > > > > > > > Best regards > > > > > > > > > > Tobias > > > > > > > > Hi Tobias, > > > > > > > > That's not what I'm suggesting. > > > > > > > > I'm suggesting that nova-compute code from upstream simply ignores > > > > completely anything related to db connection, so we're done with the > > > > topic. That is, if nova-compute process having access to the db is the > > > > issue we're trying to fix. > > > > > > > > Or is it that the security problem is having the db credentials > > > > written > > > > in a file on the compute node? If so, isn't having hacked root (or > > > > nova) > > > > access to a compute node already game-over? > > > > > > > > What are we trying to secure here? If that's what I'm thinking (ie: > > > > some > > > > VM code to escape from guest, and potentially the hacker can gain > > > > access > > > > to the db), then IMO that's not the way to enforce things. It's not > > > > the > > > > role of upstream Nova to do this apart from a well enough written > > > > documentation. > > > > > > I always understood this as having a goal to limit the attack surface. > > > So if a VM escapes out of the sandbox and access the hypervisor then > > > limit how may other services get compromised outside of the compromised > > > compute host. > > > > > > > I can agree with this in theory, however I don't think it's nova's > > responsibility to enforce this. > > > nova need to enforce it as we use the absense or present of the db creads to know > if common code is running in the compute agent or in controller services it activly breaks the nova compute agent if they > are present. > Seems like a poor choice to have made to use db creds to determine functionality but OK. > it is a bug to have the db cred in the set fo configs passed to nova-comptue and it has been for years. > the fact it worked in some case does not change teh fact this was unsupported following a depercation cycle and activly > depenedon in code after allowing operators, packagers and deployment tool maintianer years to ensure its no longer presnt. > > we could make this just a ERROR log without the hard fail but that would still not change the fact there is a bug in packages or deployment > tools that should be fixed. > > > IMHO a warning about this condition > > should be sufficient from a project standpoint. It's up to the > > operator to ensure this does not happen and not the project. > > > that would be true if it was not something that the code relied on to function correctly. > local condocutor mode was removed in grizzly, since then the db creds have been unsued in the compute node. > when cells v2 was intoduced they were used to determin if we would check the version in the local cell or in all cells > as aprt of rpc automatic upgarde level calulation. we now always to the auto discovery which cause it to break. > > > The > > project can't foresee how the service is actually going to be > > deployed. > > > we can define which methods of deployment we will support however. No? I don't think that's ever been a thing for openstack services. > > In theory this is moot if the compute service is running on > > the same host as the api and not in something like a container. > not really we have expected nova-compute to not use nova.conf in an all in one deployment since rocky unless its > in a container where it has a rendered version that only contains the section relevent to it. file names were place holders. And since you don't control the deployment, you don't pick the names (see this thread)... > > Escaping the service and having access to the host won't prevent the > > hacker from reading /etc/nova/nova-db.conf instead of > > /etc/nova/nova-compute.conf. > it wont but /etc/nova/nova-db.conf should not be on the compute node > unless you are also deploying a service that will actully use it there. > that is vald to do but it shoudl still not be bassed to the nova-comptue binary. You're missing the point if the operator is deploying nova-api and compute on the same host, they will be there. It may not be a best practice but it is something that people do for their own reasons. Nova should not artificially restrict this for no other reason than you think it shouldn't be done or you wrote code assuming this. The whole point of openstack was to allow folks to build their own clouds. If deployment decisions are being made at a project level now, then that seems to be a break in how things have been done historically. Having handled tooling around the deployment of openstack now for nearly 6 years, I'm not certain projects should necessarily be dictating this. I raised my concerns about this when this concept was first explained to me in #puppet-openstack and I've basically washed my hands of it. I disagree with this entire thing, but my take was if you're going to do it then nova developers needs to ensure it's supported in all the places and properly explained to operators which seems like the plan from this thread. I still don't think it's a good idea to hard fail but carry on. > > > Cheers, > > > gibi > > > > > > > > > > > Cheers, > > > > > > > > Thomas Goirand (zigo) > > > > > > > > > > > > > > > > > > > > From dms at danplanet.com Mon Nov 23 14:25:47 2020 From: dms at danplanet.com (Dan Smith) Date: Mon, 23 Nov 2020 06:25:47 -0800 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: (=?utf-8?Q?=22Bal=C3=A1zs?= Gibizer"'s message of "Mon, 23 Nov 2020 11:09:35 +0100") References: <519018307.59148790.1605865616072.JavaMail.zimbra@redhat.com> Message-ID: > We quickly touch this topic before on IRC and it is considered a huge > work to tag each nova config option with the service it uses. So I > would not think it will happen without figuring out a gradual approach > and having people signing up to help. It's also subject to change, so there needs to be maintenance of it going forward. It can also change _according_ to the config (i.e. configdrive uses metadata api bits on the compute, but not otherwise). --Dan From fungi at yuggoth.org Mon Nov 23 14:34:42 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 23 Nov 2020 14:34:42 +0000 Subject: [telemetry] wallaby cycle planning session In-Reply-To: <70c7a2ab-70e3-e0f7-723d-eafb619a893b@matthias-runge.de> References: <0aa17d80-4bcd-eb66-41d6-5d9f0c5aa12b@debian.org> <20201121142639.2bmljzki4pjoye27@yuggoth.org> <70c7a2ab-70e3-e0f7-723d-eafb619a893b@matthias-runge.de> Message-ID: <20201123143441.zznhk4qo23kidz6q@yuggoth.org> On 2020-11-23 09:07:51 +0100 (+0100), Matthias Runge wrote: [...] > On a side note, is anyone aware of a service like "doodle", but without > privacy issues? (I was expecting protest about using doodle as well). If you're looking for a general survey tool, Limesurvey is entirely free/libre open source software, we've got a proof of concept for it running with some minimal survey admin docs here if you want to try setting up a survey: https://docs.opendev.org/opendev/system-config/latest/survey.html#admin-survey-user Depending on what you used Doodle for though, something as simple as https://framadate.org/ (also open source but you can choose to use their free hosted version) can work rather well. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From fungi at yuggoth.org Mon Nov 23 14:37:41 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 23 Nov 2020 14:37:41 +0000 Subject: [nova] heads up about the limitations of the new gerrit In-Reply-To: References: Message-ID: <20201123143740.nguneluaamtfea6x@yuggoth.org> On 2020-11-23 11:48:15 +0100 (+0100), Balázs Gibizer wrote: > We have the new shiny gerrit. But please be aware the limitations[1]. I want > to highlight one. The launchpad - gerrit integration does not work so the > bluperints and bugs are not updated in launchpad based on the changes in > gerrit. So please manually update launchpad. More specifically, it should comment on LP bugs when changes merge or are abandoned, but at the moment it won't when changes are proposed. And yes, blueprint commenting is entirely disabled until it can be redesigned. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From hberaud at redhat.com Mon Nov 23 14:51:36 2020 From: hberaud at redhat.com (Herve Beraud) Date: Mon, 23 Nov 2020 15:51:36 +0100 Subject: [oslo] following or not following the DST changes for our meeting time In-Reply-To: References: <0b678739-086a-2a6c-7809-3c759bb1145d@suse.com> Message-ID: To summarize, our meeting will be at 3pm UTC during European DST and 4pm UTC when European DST ends. We will start adopting these new meeting time slots next week (week 49 - Monday, November 30) to allow everybody to organize their time accordingly. Thanks to everyone who joined the discussion. Le jeu. 19 nov. 2020 à 15:02, Herve Beraud a écrit : > Good point, I considered the Europe DST, as the origin of the discussion > was mostly from European people of the team. > > Is it fit well for you all? > > Le jeu. 19 nov. 2020 à 14:54, Andreas Jaeger a écrit : > >> On 16.11.20 14:50, Herve Beraud wrote: >> > Hello Oslofolk, >> > >> > As discussed during our previous meeting, at each DST change, the agenda >> > of some of us conflicting with our Oslo meeting time slot, this thread >> > just wants to propose a solution to avoid that. >> > >> > We could just move our meeting time when DST changes, and then move back >> > to this slot once DST is back. >> > >> > Right now our meeting time is UTC based, we suppose that UTC is required >> > because of the OpenStack meeting tooling. >> > >> > By following that we will get the following time slots: >> > >> > - meeting time slot when DST start: 5:00pm UTC >> > >> > - meeting time slot when DST end: 4:00pm UTC >> > >> > Does it fit well for you? >> >> Just one comment: Which country are you taking as reference? as an >> example DST in Europe, US, and Australia are at totally different times... >> >> so, best to clarify what you take as reference to avoid confusion - >> especially for those few weeks when the US has DST but Europe not - >> leaving the southern hemisphere out of this, >> >> Andreas >> -- >> Andreas Jaeger aj at suse.com Twitter: jaegerandi >> SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg >> (HRB 36809, AG Nürnberg) GF: Felix Imendörffer >> GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB >> >> >> > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.bell at cern.ch Mon Nov 23 15:14:31 2020 From: tim.bell at cern.ch (Tim Bell) Date: Mon, 23 Nov 2020 16:14:31 +0100 Subject: [telemetry] wallaby cycle planning session In-Reply-To: <20201123143441.zznhk4qo23kidz6q@yuggoth.org> References: <0aa17d80-4bcd-eb66-41d6-5d9f0c5aa12b@debian.org> <20201121142639.2bmljzki4pjoye27@yuggoth.org> <70c7a2ab-70e3-e0f7-723d-eafb619a893b@matthias-runge.de> <20201123143441.zznhk4qo23kidz6q@yuggoth.org> Message-ID: <4E266B1A-82C7-4444-AAC9-7386104B35D5@cern.ch> > On 23 Nov 2020, at 15:34, Jeremy Stanley wrote: > > On 2020-11-23 09:07:51 +0100 (+0100), Matthias Runge wrote: > [...] >> On a side note, is anyone aware of a service like "doodle", but without >> privacy issues? (I was expecting protest about using doodle as well). > > If you're looking for a general survey tool, Limesurvey is entirely > free/libre open source software, we've got a proof of concept for it > running with some minimal survey admin docs here if you want to try > setting up a survey: > > https://docs.opendev.org/opendev/system-config/latest/survey.html#admin-survey-user > > Depending on what you used Doodle for though, something as simple as > https://framadate.org/ (also open source but you can choose to use > their free hosted version) can work rather well. CERN has also a tool called newdle (https://github.com/indico/newdle ) if you want to run something on-premise. I understand it can be run standalone or as part of the Indico conferencing system (used at CERN, UN and many other places - https://github.com/indico ) Tim > -- > Jeremy Stanley -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbasaras at gmail.com Mon Nov 23 15:20:49 2020 From: pbasaras at gmail.com (Pavlos Basaras) Date: Mon, 23 Nov 2020 17:20:49 +0200 Subject: [neutron] Cannot deploy instance in provider network openstack Ussuri -- network fails In-Reply-To: References: <20201123115237.moahcpvoreslx4wk@p1.localdomain> Message-ID: Hello, adding sudo sysctl net.ipv6.conf.all.disable_ipv6=1 to the compute node solved the problem thanks, Pavlos. On Mon, Nov 23, 2020 at 3:52 PM Pavlos Basaras wrote: > Hello, > > I double checked the configuration with: > https://docs.openstack.org/neutron/ussuri/install/compute-install-ubuntu.html > , > it looks ok, i think. > > attached the log from the compute node. Do you need any other log files ? > > As i am a newbie i don't really know how to "open an LP bug " > > > all the best > Pavlos. > > On Mon, Nov 23, 2020 at 1:52 PM Slawek Kaplonski > wrote: > >> Hi, >> >> On Mon, Nov 23, 2020 at 12:11:55PM +0200, Pavlos Basaras wrote: >> > Hello, >> > >> > i am new to Openstack. >> > >> > I have followed the instructions from >> > https://docs.openstack.org/install-guide/ to install openstack Ussuri >> where >> > i use a controller node and a compute node (i can ping each other and >> > access the internet from both nodes through the mgmt iface). >> > >> > I use ubuntu 18.04 for all components. >> > >> > I have configured the network option 2, seems to work fine: >> > >> > openstack network agent list >> > >> +--------------------------------------+--------------------+------------+-------------------+-------+-------+---------------------------+ >> > | ID | Agent Type | Host >> | >> > Availability Zone | Alive | State | Binary | >> > >> +--------------------------------------+--------------------+------------+-------------------+-------+-------+---------------------------+ >> > | 2d8c3a89-32c4-4b97-aa4f-ca19db53b24f | L3 agent | >> controller | >> > nova | :-) | UP | neutron-l3-agent | >> > | 413cd13d-88d7-45ce-8b2e-26fdb265740f | Metadata agent | >> controller | >> > None | :-) | UP | neutron-metadata-agent | >> > | 42f57bee-63b3-44e6-9392-939ece98719d | Linux bridge agent | compute >> | >> > None | :-) | UP | neutron-linuxbridge-agent | >> > | 4a787a09-04aa-4350-bd32-0c0177ed06a1 | DHCP agent | >> controller | >> > nova | :-) | UP | neutron-dhcp-agent | >> > | fdafc337-7581-4ecd-b175-810713a25e1f | Linux bridge agent | >> controller | >> > None | :-) | UP | neutron-linuxbridge-agent | >> > >> +--------------------------------------+--------------------+------------+-------------------+-------+-------+---------------------------+ >> > >> > If i try to bring up instances connected by an internal network, they >> are >> > successfully deployed. >> > >> > When i use the provider network to bring up an instance with the >> command: >> > openstack server create --flavor m1.tiny --image cirros034 --nic >> > net-id=4463e4a7-3b06-46d9-b24f-3e2e7867ee96 >> > --security-group=5cf380e5-efb3-48b3-b8e9-095b1ebd817d provider-instance >> > >> > the instance fails to be instantiated because the network cannot be >> > deployed. >> > >> > I noticed two points from the neutron-linuxbridge-agent.log file at the >> > compute node (the logs at the controller seem fine): >> > >> > 1) ERROR neutron.plugins.ml2.drivers.agent._common_agent >> > pyroute2.netlink.exceptions.NetlinkError: (13, 'Permission denied') >> >> This sounds like maybe some issue with usage of sudo by user which runs >> neutron-linuxbridge-agent. Is it configured properly? >> >> > 2) INFO neutron.plugins.ml2.drivers.agent._common_agent >> > [req-816902d4-6581-49c1-939a-6ea69b437c99 - - - - -] Linux bridge agent >> > Agent out of sync with plugin! -- not sure if this one is a problem. >> >> This is probably just a result of above error. But to be sure I would >> need to >> see whole log. >> >> If You will still have such issue, please open LP bug and attach Your logs >> there. In such way it should be maybe easier to investigate what is going >> on >> there. >> >> In Ussuri we are running CI job >> neutron-tempest-plugin-scenario-linuxbridge >> which deploys neutron-linuxbridge-agent and all works fine there. You can >> check >> that e.g. on >> >> https://zuul.opendev.org/t/openstack/build/441182cb87fd47daa34d5018fc2eb9ab >> >> > >> > One part that i am not sure is the following configuration since i am on >> > ubuntu 18 and not ubuntu 16: >> > >> > # The provider network interface >> > auto INTERFACE_NAME >> > iface INTERFACE_NAME inet manual >> > up ip link set dev $IFACE up >> > down ip link set dev $IFACE down >> > >> > I did not include this part in my file since its ubuntu 18, and netplan >> > does not have an equivalent (i think) option. I have this netplan config >> > >> > enp0s8: --> mgmt >> > dhcp4: false >> > addresses: [10.0.0.31/24] >> > gateway4: 10.0.0.1 >> > nameservers: >> > addresses: [8.8.8.8, 8.8.4.4] >> > enp0s9: --> provider >> > dhcp4: false >> > >> > >> > >> > any advice? >> > >> > all the best, >> > Pavlos Basaras >> >> -- >> Slawek Kaplonski >> Principal Software Engineer >> Red Hat >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrunge at matthias-runge.de Mon Nov 23 15:31:00 2020 From: mrunge at matthias-runge.de (Matthias Runge) Date: Mon, 23 Nov 2020 16:31:00 +0100 Subject: [telemetry] wallaby cycle planning session In-Reply-To: <4E266B1A-82C7-4444-AAC9-7386104B35D5@cern.ch> References: <0aa17d80-4bcd-eb66-41d6-5d9f0c5aa12b@debian.org> <20201121142639.2bmljzki4pjoye27@yuggoth.org> <70c7a2ab-70e3-e0f7-723d-eafb619a893b@matthias-runge.de> <20201123143441.zznhk4qo23kidz6q@yuggoth.org> <4E266B1A-82C7-4444-AAC9-7386104B35D5@cern.ch> Message-ID: <17286beb-7975-644c-a292-cde00804b1aa@matthias-runge.de> On 23/11/2020 16:14, Tim Bell wrote: >> On 23 Nov 2020, at 15:34, Jeremy Stanley > > wrote: >> >> On 2020-11-23 09:07:51 +0100 (+0100), Matthias Runge wrote: >> [...] >>> On a side note, is anyone aware of a service like "doodle", but without >>> privacy issues? (I was expecting protest about using doodle as well). >> >> If you're looking for a general survey tool, Limesurvey is entirely >> free/libre open source software, we've got a proof of concept for it >> running with some minimal survey admin docs here if you want to try >> setting up a survey: >> >> https://docs.opendev.org/opendev/system-config/latest/survey.html#admin-survey-user >> >> >> Depending on what you used Doodle for though, something as simple as >> https://framadate.org/ (also open source but you can choose to use >> their free hosted version) can work rather well. > > CERN has also a tool called newdle (https://github.com/indico/newdle > ) if you want to run something > on-premise. I understand it can be run standalone or as part of the > Indico conferencing system (used at CERN, UN and many other places - > https://github.com/indico ) > Thank you both, this is good to know, and I'll definitely keep them in mind next time. The tool I found (a students re-implentation of the scheduling version from doodle) had issues with multiple time zones. Matthias From smooney at redhat.com Mon Nov 23 15:39:14 2020 From: smooney at redhat.com (Sean Mooney) Date: Mon, 23 Nov 2020 15:39:14 +0000 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: <6feed46a-c1b8-74ac-f59a-d45b2bfefd67@debian.org> <4b2eb7c4b98846628e1d1e8e389ccc5f@binero.com> <0a5ae0ef-463c-3691-60a2-fc6d85520c23@debian.org> <7EW8KQ.UNB9NASIF2Q11@est.tech> Message-ID: On Mon, 2020-11-23 at 07:02 -0700, Alex Schultz wrote: > On Mon, Nov 23, 2020 at 6:42 AM Sean Mooney wrote: > > > > On Mon, 2020-11-23 at 06:15 -0700, Alex Schultz wrote: > > > On Mon, Nov 23, 2020 at 3:47 AM Balázs Gibizer wrote: > > > > > > > > > > > > > > > > On Mon, Nov 23, 2020 at 11:18, Thomas Goirand wrote: > > > > > On 11/23/20 9:30 AM, Tobias Urdin wrote: > > > > > >  Hello, > > > > > > > > > > > > > > > > > >  Just to clarify that this is already possible when using > > > > > >  puppet-nova, it's up to the deployment to > > > > > > > > > > > >  make sure the database parameters for the classes is set. > > > > > > > > > > > > > > > > > >  We've been running without database credentials in nova.conf on our > > > > > >  compute nodes for years. > > > > > > > > > > > > > > > > > >  Best regards > > > > > > > > > > > >  Tobias > > > > > > > > > > Hi Tobias, > > > > > > > > > > That's not what I'm suggesting. > > > > > > > > > > I'm suggesting that nova-compute code from upstream simply ignores > > > > > completely anything related to db connection, so we're done with the > > > > > topic. That is, if nova-compute process having access to the db is the > > > > > issue we're trying to fix. > > > > > > > > > > Or is it that the security problem is having the db credentials > > > > > written > > > > > in a file on the compute node? If so, isn't having hacked root (or > > > > > nova) > > > > > access to a compute node already game-over? > > > > > > > > > > What are we trying to secure here? If that's what I'm thinking (ie: > > > > > some > > > > > VM code to escape from guest, and potentially the hacker can gain > > > > > access > > > > > to the db), then IMO that's not the way to enforce things. It's not > > > > > the > > > > > role of upstream Nova to do this apart from a well enough written > > > > > documentation. > > > > > > > > I always understood this as having a goal to limit the attack surface. > > > > So if a VM escapes out of the sandbox and access the hypervisor then > > > > limit how may other services get compromised outside of the compromised > > > > compute host. > > > > > > > > > > I can agree with this in theory, however I don't think it's nova's > > > responsibility to enforce this. > > > > > nova need to enforce it as we use the absense or present of the db creads to know > > if common code is running in the compute agent or in controller services it activly breaks the nova compute agent if they > > are present. > > > > Seems like a poor choice to have made to use db creds to determine > functionality but OK. the code in question use the config options to know if it can connect directly to the db to lookup the min service versionor if it must do an rpc via the conductor. for the api it would be ineffecnt for ti to call the conductor since it has direct db acess. for the compute nodes they have to call the conductor since they dont. the only other way to adress this woudl be to check the binary name or something else equally unclean. > > > it is a bug to have the db cred in the set fo configs passed to nova-comptue and it has been for years. > > the fact it worked in some case does not change teh fact this was unsupported following a depercation cycle and activly > > depenedon in code after allowing operators, packagers and deployment tool maintianer years to ensure its no longer presnt. > > > > we could make this just a ERROR log without the hard fail but that would still not change the fact there is a bug in packages or deployment > > tools that should be fixed. > > > > >   IMHO a warning about this condition > > > should be sufficient from a project standpoint. It's up to the > > > operator to ensure this does not happen and not the project. > > > > > that would be true if it was not something that the code relied on to function correctly. > > local condocutor mode was removed in grizzly, since then the db creds have been unsued in the compute node. > > when cells v2 was intoduced they were used to determin if we would check the version in the local cell or in all cells > > as aprt of rpc automatic upgarde level calulation. we now always to the auto discovery which cause it to break. > > > > >   The > > > project can't foresee how the service is actually going to be > > > deployed. > > > > > we can define which methods of deployment we will support however. > > No? I don't think that's ever been a thing for openstack services. > > > >   In theory this is moot if the compute service is running on > > > the same host as the api and not in something like a container. > > not really we have expected nova-compute to not use nova.conf in an all in one deployment since rocky unless its > > in a container where it has a rendered version that only contains the section relevent to it. > > file names were place holders. And since you don't control the > deployment, you don't pick the names (see this thread)... > > > > Escaping the service and having access to the host won't prevent the > > > hacker from reading /etc/nova/nova-db.conf instead of > > > /etc/nova/nova-compute.conf. > > it wont but /etc/nova/nova-db.conf should not be on the compute node > > unless you are also deploying a service that will actully use it there. > > that is vald to do but it shoudl still not be bassed to the nova-comptue binary. > > You're missing the point if the operator is deploying nova-api and > compute on the same host, they will be there. It may not be a best > practice but it is something that people do for their own reasons. im not missing that point my point was if you wnat to do that its fine nova-compute should just not use the same config file as nova-api. yes its a deployment choice what the file names are but its was and has been a requirement that nova-compute should not have the db creds so if you have a service that needs them you had two choices to not violate that. 1 have nova-compute use its own config file e..g n-cpu.conf and only add the section that it needs 2 have nova-compute use nova.conf and have the second service use a secondary config file with there are two best practices with regards to the config 1 for each service to have its own config file with only the subset of info they require or 2 for nova.conf to have the general setting common to all services and the service config to have the addtional setting relevent only to them optionally factoring out possible shared info into extra config like nova-db.conf i personally have a very stong preferecne for each service having its own cofnig with a shared nothing approch on the filesystem and using templates to generage teh config. if you are doing it by had i see the other approch as vaild too where you compose multiple files each of which has a minimal subset of options for a singel feature set or service. the db creds are one example of this, the pci passthrough alias defintion which are shared between nova-comptue and the nova-api are another example. we are not going to stop supporting topologies our your freedom as an operator to deploy the service in a way that meets your needs however we do reserve the right to deprecate and remote options and either ignore or treat them as an error in the future. if we removed a commandline option form a cli we would warn and or treat that as an error in a similar way inline with our upgrade and deperacation proceduces. > Nova should not artificially restrict this for no other reason than > you think it shouldn't be done or you wrote code assuming this. The > whole point of openstack was to allow folks to build their own clouds. > If deployment decisions are being made at a project level now, then > that seems to be a break in how things have been done historically. > Having handled tooling around the deployment of openstack now for > nearly 6 years, I'm not certain projects should necessarily be > dictating this. > > I raised my concerns about this when this concept was first explained > to me in #puppet-openstack and I've basically washed my hands of it. I > disagree with this entire thing, but my take was if you're going to do > it then nova developers needs to ensure it's supported in all the > places and properly explained to operators which seems like the plan > from this thread. I still don't think it's a good idea to hard fail > but carry on. > > > > > Cheers, > > > > gibi > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Thomas Goirand (zigo) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From balazs.gibizer at est.tech Mon Nov 23 15:50:29 2020 From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer) Date: Mon, 23 Nov 2020 16:50:29 +0100 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] =?UTF-8?Q?Nova=0D=0A?= enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: <6feed46a-c1b8-74ac-f59a-d45b2bfefd67@debian.org> <4b2eb7c4b98846628e1d1e8e389ccc5f@binero.com> <0a5ae0ef-463c-3691-60a2-fc6d85520c23@debian.org> <7EW8KQ.UNB9NASIF2Q11@est.tech> Message-ID: <5OA9KQ.IX4E6VEUTLST2@est.tech> On Mon, Nov 23, 2020 at 07:02, Alex Schultz wrote: > On Mon, Nov 23, 2020 at 6:42 AM Sean Mooney > wrote: >> >> On Mon, 2020-11-23 at 06:15 -0700, Alex Schultz wrote: >> > On Mon, Nov 23, 2020 at 3:47 AM Balázs Gibizer >> wrote: >> > > >> > > >> > > >> > > On Mon, Nov 23, 2020 at 11:18, Thomas Goirand >> wrote: >> > > > On 11/23/20 9:30 AM, Tobias Urdin wrote: >> > > > > Hello, >> > > > > >> > > > > >> > > > > Just to clarify that this is already possible when using >> > > > > puppet-nova, it's up to the deployment to >> > > > > >> > > > > make sure the database parameters for the classes is set. >> > > > > >> > > > > >> > > > > We've been running without database credentials in >> nova.conf on our >> > > > > compute nodes for years. >> > > > > >> > > > > >> > > > > Best regards >> > > > > >> > > > > Tobias >> > > > >> > > > Hi Tobias, >> > > > >> > > > That's not what I'm suggesting. >> > > > >> > > > I'm suggesting that nova-compute code from upstream simply >> ignores >> > > > completely anything related to db connection, so we're done >> with the >> > > > topic. That is, if nova-compute process having access to the >> db is the >> > > > issue we're trying to fix. >> > > > >> > > > Or is it that the security problem is having the db >> credentials >> > > > written >> > > > in a file on the compute node? If so, isn't having hacked >> root (or >> > > > nova) >> > > > access to a compute node already game-over? >> > > > >> > > > What are we trying to secure here? If that's what I'm >> thinking (ie: >> > > > some >> > > > VM code to escape from guest, and potentially the hacker can >> gain >> > > > access >> > > > to the db), then IMO that's not the way to enforce things. >> It's not >> > > > the >> > > > role of upstream Nova to do this apart from a well enough >> written >> > > > documentation. >> > > >> > > I always understood this as having a goal to limit the attack >> surface. >> > > So if a VM escapes out of the sandbox and access the hypervisor >> then >> > > limit how may other services get compromised outside of the >> compromised >> > > compute host. >> > > >> > >> > I can agree with this in theory, however I don't think it's nova's >> > responsibility to enforce this. >> > >> nova need to enforce it as we use the absense or present of the db >> creads to know >> if common code is running in the compute agent or in controller >> services it activly breaks the nova compute agent if they >> are present. >> > > Seems like a poor choice to have made to use db creds to determine > functionality but OK. > >> it is a bug to have the db cred in the set fo configs passed to >> nova-comptue and it has been for years. >> the fact it worked in some case does not change teh fact this was >> unsupported following a depercation cycle and activly >> depenedon in code after allowing operators, packagers and >> deployment tool maintianer years to ensure its no longer presnt. >> >> we could make this just a ERROR log without the hard fail but that >> would still not change the fact there is a bug in packages or >> deployment >> tools that should be fixed. >> >> > IMHO a warning about this condition >> > should be sufficient from a project standpoint. It's up to the >> > operator to ensure this does not happen and not the project. >> > >> that would be true if it was not something that the code relied on >> to function correctly. >> local condocutor mode was removed in grizzly, since then the db >> creds have been unsued in the compute node. >> when cells v2 was intoduced they were used to determin if we would >> check the version in the local cell or in all cells >> as aprt of rpc automatic upgarde level calulation. we now always to >> the auto discovery which cause it to break. >> >> > The >> > project can't foresee how the service is actually going to be >> > deployed. >> > >> we can define which methods of deployment we will support however. > > No? I don't think that's ever been a thing for openstack services. > >> > In theory this is moot if the compute service is running on >> > the same host as the api and not in something like a container. >> not really we have expected nova-compute to not use nova.conf in an >> all in one deployment since rocky unless its >> in a container where it has a rendered version that only contains >> the section relevent to it. > > file names were place holders. And since you don't control the > deployment, you don't pick the names (see this thread)... > >> > Escaping the service and having access to the host won't prevent >> the >> > hacker from reading /etc/nova/nova-db.conf instead of >> > /etc/nova/nova-compute.conf. >> it wont but /etc/nova/nova-db.conf should not be on the compute >> node >> unless you are also deploying a service that will actully use it >> there. >> that is vald to do but it shoudl still not be bassed to the >> nova-comptue binary. > > You're missing the point if the operator is deploying nova-api and > compute on the same host, they will be there. It may not be a best > practice but it is something that people do for their own reasons. > Nova should not artificially restrict this for no other reason than > you think it shouldn't be done or you wrote code assuming this. The > whole point of openstack was to allow folks to build their own clouds. > If deployment decisions are being made at a project level now, then > that seems to be a break in how things have been done historically. > Having handled tooling around the deployment of openstack now for > nearly 6 years, I'm not certain projects should necessarily be > dictating this. To be fair with this change we are not dictating that nova-api and nova-compute cannot be deployed to the same host. We only dictate that they cannot use the same config file if they are deployed together. I don't see this (e.g. two binaries on the same host needs two separate config files) as a big restriction, but I might be mistaken. Also this is not the first time nova-compute refuse to start if provided with an invalid configuration. There are a bunch of those cases in the compute manager or in the virt driver e.g. [1]. [1] https://github.com/openstack/nova/blob/ab90c7af5626db190752528bba1d4982a8a0dac1/nova/compute/manager.py#L838 > > I raised my concerns about this when this concept was first explained > to me in #puppet-openstack and I've basically washed my hands of it. I > disagree with this entire thing, but my take was if you're going to do > it then nova developers needs to ensure it's supported in all the > places and properly explained to operators which seems like the plan > from this thread. I still don't think it's a good idea to hard fail > but carry on. > >> > > Cheers, >> > > gibi >> > > >> > > > >> > > > Cheers, >> > > > >> > > > Thomas Goirand (zigo) >> > > > >> > > >> > > >> > > >> > >> > >> >> >> > > From rafaelweingartner at gmail.com Mon Nov 23 16:48:37 2020 From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=) Date: Mon, 23 Nov 2020 13:48:37 -0300 Subject: [telemetry] wallaby cycle planning session In-Reply-To: <17286beb-7975-644c-a292-cde00804b1aa@matthias-runge.de> References: <0aa17d80-4bcd-eb66-41d6-5d9f0c5aa12b@debian.org> <20201121142639.2bmljzki4pjoye27@yuggoth.org> <70c7a2ab-70e3-e0f7-723d-eafb619a893b@matthias-runge.de> <20201123143441.zznhk4qo23kidz6q@yuggoth.org> <4E266B1A-82C7-4444-AAC9-7386104B35D5@cern.ch> <17286beb-7975-644c-a292-cde00804b1aa@matthias-runge.de> Message-ID: Hello guys, I got a bit lost throughout the thread. Do we already have a meeting place (Zoom, meet, or some other method/place)? On Mon, Nov 23, 2020 at 12:38 PM Matthias Runge wrote: > On 23/11/2020 16:14, Tim Bell wrote: > >> On 23 Nov 2020, at 15:34, Jeremy Stanley >> > wrote: > >> > >> On 2020-11-23 09:07:51 +0100 (+0100), Matthias Runge wrote: > >> [...] > >>> On a side note, is anyone aware of a service like "doodle", but without > >>> privacy issues? (I was expecting protest about using doodle as well). > >> > >> If you're looking for a general survey tool, Limesurvey is entirely > >> free/libre open source software, we've got a proof of concept for it > >> running with some minimal survey admin docs here if you want to try > >> setting up a survey: > >> > >> > https://docs.opendev.org/opendev/system-config/latest/survey.html#admin-survey-user > >> < > https://docs.opendev.org/opendev/system-config/latest/survey.html#admin-survey-user > > > >> > >> Depending on what you used Doodle for though, something as simple as > >> https://framadate.org/ (also open source but you can choose to use > >> their free hosted version) can work rather well. > > > > CERN has also a tool called newdle (https://github.com/indico/newdle > > ) if you want to run something > > on-premise. I understand it can be run standalone or as part of the > > Indico conferencing system (used at CERN, UN and many other places - > > https://github.com/indico ) > > > > Thank you both, this is good to know, and I'll definitely keep them in > mind next time. > > The tool I found (a students re-implentation of the scheduling version > from doodle) had issues with multiple time zones. > > Matthias > > -- Rafael Weingärtner -------------- next part -------------- An HTML attachment was scrubbed... URL: From gouthampravi at gmail.com Mon Nov 23 17:27:19 2020 From: gouthampravi at gmail.com (Goutham Pacha Ravi) Date: Mon, 23 Nov 2020 09:27:19 -0800 Subject: [manila] Proposing Maari Tamm for python-manilaclient core In-Reply-To: References: Message-ID: Thanks everyone for responding on this thread. I've added Maari to the python-manilaclient-core team. Best, Goutham On Wed, Nov 18, 2020 at 2:02 PM Victoria Martínez de la Cruz wrote: > > Hi everyone, > > It's a great pleasure for me to propose Maari Tamm (maaritamm) for the python-manilaclient core group. > > Maari joined us as an Outreachy intern working on the manila support for openstackclient in December 2019. She excelled at delivering the main task, and she went above and beyond by continuing to contribute with the community even after her internship finished. She now continues submitting enhancements for the different manila components and taking on new challenges as they appear. > > Not only that, Maari joined us as mentor for the manila project in different efforts we have made: the Open Source Day in Grace Hopper Celebration 2020 and also mentoring for three students from the Boston University that are currently working with us in manila. > > Maari is a truly valuable member of our team and I believe she will be a great addition to the python-manilaclient core reviewers group. > > Looking forward to a positive response. > > All the best, > > Victoria From zigo at debian.org Mon Nov 23 17:34:50 2020 From: zigo at debian.org (Thomas Goirand) Date: Mon, 23 Nov 2020 18:34:50 +0100 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: <6feed46a-c1b8-74ac-f59a-d45b2bfefd67@debian.org> <4b2eb7c4b98846628e1d1e8e389ccc5f@binero.com> <0a5ae0ef-463c-3691-60a2-fc6d85520c23@debian.org> <7EW8KQ.UNB9NASIF2Q11@est.tech> Message-ID: <0a119ba3-707b-057a-a2a9-d515fbb96c3a@debian.org> Hi Sean, Thanks for your post. On 11/23/20 2:32 PM, Sean Mooney wrote: > nova need to enforce it as we use the absense or present of the db creads to know > if common code is running in the compute agent or in controller services I'm a bit shocked to read what I've read in this thread, about the double-guess that Nova is doing. The way the Nova team has been describing, this really looks like hacks to hide the internals of Nova, and what the team is asking, is more band-aid for it. Probably things have been done this way to make it easier for the users, but at this point, it feels like we shouldn't attempt to hide facts anymore, and try to have everything explicit, which is going the opposite way of what you describe. Why don't we go the other way around, and get things like a superconductor=true configuration directive, for example? On 11/23/20 2:32 PM, Sean Mooney wrote: > it is a bug to have the db cred in the set fo configs passed to > nova-comptue and it has been for years. In such case, detect that it's the nova-compute agent that's running, detect that it has access to db creds, and either: - display a big warning (I would prefer that) - display an error and quit (maybe bad in the case of an all-in-one setup) This is orthogonal to the fact that Nova code is doing a hack (which should be fixed) to check which daemon is currently running in what mode. On 11/23/20 2:32 PM, Sean Mooney wrote: > we could make this just a ERROR log without the hard fail but that > would still not change the fact there is a bug in packages or > deployment tools that should be fixed. Probably. But that shouldn't be upstream author's business on how things are deployed. IMO, in the case of an all-in-one, nova-compute should continue to work and just ignore the db params, and at worse display a huge warning on the logs. With the light of this thread, my opinion now has shifted to *not* have special files for the db credential, to give Nova a chance to tell the users what to do if nova-compute detects a mistake. If we push the creds in /etc/nova/nova-db.conf, it wont be loaded by nova-compute, and it wont be able to warn the user that the file shouldn't be there on a compute node. Checking for the file existence only would be wrong (because it could have empty values and just be there ... just because it's there! :) ). Hoping sharing my view is constructive and adding value to the thread, Cheers, Thomas Goirand (zigo) From mrunge at matthias-runge.de Mon Nov 23 17:47:05 2020 From: mrunge at matthias-runge.de (Matthias Runge) Date: Mon, 23 Nov 2020 18:47:05 +0100 Subject: [telemetry] wallaby cycle planning session In-Reply-To: References: <0aa17d80-4bcd-eb66-41d6-5d9f0c5aa12b@debian.org> <20201121142639.2bmljzki4pjoye27@yuggoth.org> <70c7a2ab-70e3-e0f7-723d-eafb619a893b@matthias-runge.de> <20201123143441.zznhk4qo23kidz6q@yuggoth.org> <4E266B1A-82C7-4444-AAC9-7386104B35D5@cern.ch> <17286beb-7975-644c-a292-cde00804b1aa@matthias-runge.de> Message-ID: <0b297a58-9ff6-b3cc-3ef0-9b40ee0b9916@matthias-runge.de> On 23/11/2020 17:48, Rafael Weingärtner wrote: > Hello guys, I got a bit lost throughout the thread. Do we already have a > meeting place (Zoom, meet, or some other method/place)? > Yes, we do http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018937.html: --------------- Hi, as result, we will be meeting next Friday (Nov. 27 at 4PM CET, that is 10 AM US Eastern). If it works for you, let's use this bluejeans channel[4] for the discussion. For ideas, questions and an agenda, there is the etherpad[5]. See you there [4] https://redhat.bluejeans.com/u/mrunge/ [5] https://etherpad.opendev.org/p/telemetry-wallaby-topics ------------------- From smooney at redhat.com Mon Nov 23 18:21:22 2020 From: smooney at redhat.com (Sean Mooney) Date: Mon, 23 Nov 2020 18:21:22 +0000 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: <0a119ba3-707b-057a-a2a9-d515fbb96c3a@debian.org> References: <6feed46a-c1b8-74ac-f59a-d45b2bfefd67@debian.org> <4b2eb7c4b98846628e1d1e8e389ccc5f@binero.com> <0a5ae0ef-463c-3691-60a2-fc6d85520c23@debian.org> <7EW8KQ.UNB9NASIF2Q11@est.tech> <0a119ba3-707b-057a-a2a9-d515fbb96c3a@debian.org> Message-ID: <2a9f8c7b22322b2ed5742628a0c73aa421da358d.camel@redhat.com> On Mon, 2020-11-23 at 18:34 +0100, Thomas Goirand wrote: > Hi Sean, > > Thanks for your post. > > On 11/23/20 2:32 PM, Sean Mooney wrote: > > nova need to enforce it as we use the absense or present of the db creads to know > > if common code is running in the compute agent or in controller services > > I'm a bit shocked to read what I've read in this thread, about the > double-guess that Nova is doing. > > The way the Nova team has been describing, this really looks like hacks > to hide the internals of Nova, and what the team is asking, is more > band-aid for it. Probably things have been done this way to make it > easier for the users, but at this point, it feels like we shouldn't > attempt to hide facts anymore, and try to have everything explicit, > which is going the opposite way of what you describe. > > Why don't we go the other way around, and get things like a > superconductor=true configuration directive, for example? this would break upgrades for everyone one of our upgrade constratins is you should never have to update your config as part of an upgrade. where config changes are needed we always give you at least 1 cycle to update your configs as part of a seperate maintance window. it would also force all deployment tools and packages to chagne as we would have new portentially incompatible options in config files. spcificlly packagers would have to ship different nova config file for supper conductors and cell conductors for that usecase. > > On 11/23/20 2:32 PM, Sean Mooney wrote: > > it is a bug to have the db cred in the set fo configs passed to > > nova-comptue and it has been for years. > > In such case, detect that it's the nova-compute agent that's running, > detect that it has access to db creds, and either: > - display a big warning (I would prefer that) > - display an error and quit (maybe bad in the case of an all-in-one setup) > > This is orthogonal to the fact that Nova code is doing a hack (which > should be fixed) to check which daemon is currently running in what mode. it is not a hack, checking the binary name would be a hack as that is common code that shoudl be independnt of what name you give the file on disk. this was the where it would have failed from rocky on https://github.com/openstack/nova/blob/dc93e3b510f53d5b2198c8edd22528f0c899617e/nova/compute/rpcapi.py#L416-L421 if you used upgrade level auto but set the api db creds in teh config of the compute agent https://github.com/openstack/nova/blob/dc93e3b510f53d5b2198c8edd22528f0c899617e/nova/compute/rpcapi.py#L441-L461 if the api db options are set we get the min servie verion across all cells via a direct api call service_version = service_obj.get_minimum_version_all_cells( context.get_admin_context(), ['nova-compute']) and if they are not we do an indirect cal via the cell conductor to get the min compute service version in the local cell not that it is a remoteable method https://github.com/openstack/nova/blob/dc93e3b510f53d5b2198c8edd22528f0c899617e/nova/objects/service.py#L516-L519 so when invoked form the compute agent it is converted to an rpc to the conductor to execute the lookup. get_minimum_version_all_cells is not remoteable since calling it form a compute node would result in an upcall to iterate over all the top level cells https://github.com/openstack/nova/blob/dc93e3b510f53d5b2198c8edd22528f0c899617e/nova/objects/service.py#L522 it was part of moving to cell v2 https://github.com/openstack/nova/commit/d779b33d72d6ef41651ce7b93fe982f121bae2d7 resolving https://bugs.launchpad.net/nova/+bug/1807044 the reason for the new failure is that we now uncontionally check the min compute node version using the same logic that we used before. https://github.com/openstack/nova/blob/dc93e3b510f53d5b2198c8edd22528f0c899617e/nova/utils.py#L1057-L1087 if CONF.api_database.connection is not None: scope = 'system' current_service_version = service.get_minimum_version_all_cells( ctxt, ['nova-compute']) else: scope = 'cell' # We in a cell so target our query to the current cell only current_service_version = service.Service.get_minimum_version( ctxt, 'nova-compute') again using the presne of the db configurtion as a sentinal for is this code allowed to query the db directly. the patch that is under review to convert this to a warning just catches the excption for teh blocked direct db acess and logs the warning then execute the else branch https://review.opendev.org/c/openstack/nova/+/762175/1/nova/utils.py#1073 it is not a hack to rely on something that we have depened on for 2 years and we have stated for many more namely that the compute agent may not have the db options set. > > On 11/23/20 2:32 PM, Sean Mooney wrote: > > we could make this just a ERROR log without the hard fail but that > > would still not change the fact there is a bug in packages or > > deployment tools that should be fixed. > > Probably. But that shouldn't be upstream author's business on how things > are deployed. IMO, in the case of an all-in-one, nova-compute should > continue to work and just ignore the db params, and at worse display a > huge warning on the logs. well there i dissagree the warning/error message is the bare minium we should do and at most we should allow ti to contiue executing and optimally it should stop the service sicne we know the config is invalid. > > With the light of this thread, my opinion now has shifted to *not* have > special files for the db credential, to give Nova a chance to tell the > users what to do if nova-compute detects a mistake. > > If we push the creds in /etc/nova/nova-db.conf, it wont be loaded by > nova-compute, and it wont be able to warn the user that the file > shouldn't be there on a compute node. > that is true we cant warn for a bug in the deployment too or in your packages but that is not something nova should have to do. we can warn when you invoke us with incorreect import but we should not have to check for other mistakes you have made. > Checking for the file existence > only would be wrong (because it could have empty values and just be > there ... just because it's there! :) ). > > Hoping sharing my view is constructive and adding value to the thread, > Cheers, it is and just bacuase i dont agree with your view point does not mean i dont want to hear you express it as it chanlagnes me and other to constantly revialuate our postion based on the different persepctive shared :) > > Thomas Goirand (zigo) > From skaplons at redhat.com Mon Nov 23 22:20:17 2020 From: skaplons at redhat.com (Slawek Kaplonski) Date: Mon, 23 Nov 2020 23:20:17 +0100 Subject: [neutron] Cannot deploy instance in provider network openstack Ussuri -- network fails In-Reply-To: References: Message-ID: <7080624.0m4JU215nX@p1> Hi, Dnia poniedziałek, 23 listopada 2020 16:20:49 CET Pavlos Basaras pisze: > Hello, > > adding > sudo sysctl net.ipv6.conf.all.disable_ipv6=1 > > to the compute node solved the problem It's more like workaround not a solution really. If You will want to use IPv6 on the host, You will have the issue again. > > thanks, > Pavlos. > > On Mon, Nov 23, 2020 at 3:52 PM Pavlos Basaras wrote: > > Hello, > > > > I double checked the configuration with: > > https://docs.openstack.org/neutron/ussuri/install/compute-install-ubuntu.h > > tml , > > it looks ok, i think. > > > > attached the log from the compute node. Do you need any other log files ? > > > > As i am a newbie i don't really know how to "open an LP bug " > > > > > > all the best > > Pavlos. > > > > On Mon, Nov 23, 2020 at 1:52 PM Slawek Kaplonski > > > > wrote: > >> Hi, > >> > >> On Mon, Nov 23, 2020 at 12:11:55PM +0200, Pavlos Basaras wrote: > >> > Hello, > >> > > >> > i am new to Openstack. > >> > > >> > I have followed the instructions from > >> > https://docs.openstack.org/install-guide/ to install openstack Ussuri > >> > >> where > >> > >> > i use a controller node and a compute node (i can ping each other and > >> > access the internet from both nodes through the mgmt iface). > >> > > >> > I use ubuntu 18.04 for all components. > >> > > >> > I have configured the network option 2, seems to work fine: > >> > > >> > openstack network agent list > >> > >> +--------------------------------------+--------------------+------------ > >> +-------------------+-------+-------+---------------------------+>> > >> > | ID | Agent Type | Host > >> > > >> > Availability Zone | Alive | State | Binary | > >> > >> +--------------------------------------+--------------------+------------ > >> +-------------------+-------+-------+---------------------------+>> > >> > | 2d8c3a89-32c4-4b97-aa4f-ca19db53b24f | L3 agent | > >> > >> controller | > >> > >> > nova | :-) | UP | neutron-l3-agent | > >> > > >> > | 413cd13d-88d7-45ce-8b2e-26fdb265740f | Metadata agent | > >> > >> controller | > >> > >> > None | :-) | UP | neutron-metadata-agent | > >> > > >> > | 42f57bee-63b3-44e6-9392-939ece98719d | Linux bridge agent | compute > >> > > >> > None | :-) | UP | neutron-linuxbridge-agent | > >> > > >> > | 4a787a09-04aa-4350-bd32-0c0177ed06a1 | DHCP agent | > >> > >> controller | > >> > >> > nova | :-) | UP | neutron-dhcp-agent | > >> > > >> > | fdafc337-7581-4ecd-b175-810713a25e1f | Linux bridge agent | > >> > >> controller | > >> > >> > None | :-) | UP | neutron-linuxbridge-agent | > >> > >> +--------------------------------------+--------------------+------------ > >> +-------------------+-------+-------+---------------------------+>> > >> > If i try to bring up instances connected by an internal network, they > >> > >> are > >> > >> > successfully deployed. > >> > > >> > When i use the provider network to bring up an instance with the > >> > >> command: > >> > openstack server create --flavor m1.tiny --image cirros034 --nic > >> > net-id=4463e4a7-3b06-46d9-b24f-3e2e7867ee96 > >> > --security-group=5cf380e5-efb3-48b3-b8e9-095b1ebd817d provider-instance > >> > > >> > the instance fails to be instantiated because the network cannot be > >> > deployed. > >> > > >> > I noticed two points from the neutron-linuxbridge-agent.log file at the > >> > compute node (the logs at the controller seem fine): > >> > > >> > 1) ERROR neutron.plugins.ml2.drivers.agent._common_agent > >> > pyroute2.netlink.exceptions.NetlinkError: (13, 'Permission denied') > >> > >> This sounds like maybe some issue with usage of sudo by user which runs > >> neutron-linuxbridge-agent. Is it configured properly? > >> > >> > 2) INFO neutron.plugins.ml2.drivers.agent._common_agent > >> > [req-816902d4-6581-49c1-939a-6ea69b437c99 - - - - -] Linux bridge agent > >> > Agent out of sync with plugin! -- not sure if this one is a problem. > >> > >> This is probably just a result of above error. But to be sure I would > >> need to > >> see whole log. > >> > >> If You will still have such issue, please open LP bug and attach Your > >> logs > >> there. In such way it should be maybe easier to investigate what is going > >> on > >> there. > >> > >> In Ussuri we are running CI job > >> neutron-tempest-plugin-scenario-linuxbridge > >> which deploys neutron-linuxbridge-agent and all works fine there. You can > >> check > >> that e.g. on > >> > >> https://zuul.opendev.org/t/openstack/build/441182cb87fd47daa34d5018fc2eb9 > >> ab > >> > >> > One part that i am not sure is the following configuration since i am > >> > on > >> > ubuntu 18 and not ubuntu 16: > >> > > >> > # The provider network interface > >> > auto INTERFACE_NAME > >> > iface INTERFACE_NAME inet manual > >> > up ip link set dev $IFACE up > >> > down ip link set dev $IFACE down > >> > > >> > I did not include this part in my file since its ubuntu 18, and netplan > >> > does not have an equivalent (i think) option. I have this netplan > >> > config > >> > > >> > enp0s8: --> mgmt > >> > > >> > dhcp4: false > >> > addresses: [10.0.0.31/24] > >> > gateway4: 10.0.0.1 > >> > > >> > nameservers: > >> > addresses: [8.8.8.8, 8.8.4.4] > >> > > >> > enp0s9: --> provider > >> > > >> > dhcp4: false > >> > > >> > any advice? > >> > > >> > all the best, > >> > Pavlos Basaras > >> > >> -- > >> Slawek Kaplonski > >> Principal Software Engineer > >> Red Hat -- Slawek Kaplonski Principal Software Engineer Red Hat From amy at demarco.com Mon Nov 23 22:46:14 2020 From: amy at demarco.com (Amy Marrich) Date: Mon, 23 Nov 2020 16:46:14 -0600 Subject: RDO Community Meeting Update Message-ID: During the virtual Get Together, we decided to have the first meeting of the month virtually to help with the lack of face to face time between contributors at events. Please join us during the virtual meetings using the following link: meet.google.com/uzo-tfkt-top We will also be keeping notes within the #rdo channel on Freenode for our normal post-meeting sharing so if you can not join us virtually please join us via IRC as usual. Thanks and hope to see everyone virtually on December 2nd at 14:00 UTC! Amy (spotz) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.urdin at binero.com Mon Nov 23 23:10:59 2020 From: tobias.urdin at binero.com (Tobias Urdin) Date: Mon, 23 Nov 2020 23:10:59 +0000 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: <0a5ae0ef-463c-3691-60a2-fc6d85520c23@debian.org> References: <6feed46a-c1b8-74ac-f59a-d45b2bfefd67@debian.org> <4b2eb7c4b98846628e1d1e8e389ccc5f@binero.com>, <0a5ae0ef-463c-3691-60a2-fc6d85520c23@debian.org> Message-ID: <0db918b582bb4dda85541e228a6f0813@binero.com> Sorry, It was not suppose to be a reply to your specifically but to thread as a whole. Best regards ________________________________ From: Thomas Goirand Sent: Monday, November 23, 2020 11:18:25 AM To: openstack maillist Subject: Re: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service On 11/23/20 9:30 AM, Tobias Urdin wrote: > Hello, > > > Just to clarify that this is already possible when using > puppet-nova, it's up to the deployment to > > make sure the database parameters for the classes is set. > > > We've been running without database credentials in nova.conf on our > compute nodes for years. > > > Best regards > > Tobias Hi Tobias, That's not what I'm suggesting. I'm suggesting that nova-compute code from upstream simply ignores completely anything related to db connection, so we're done with the topic. That is, if nova-compute process having access to the db is the issue we're trying to fix. Or is it that the security problem is having the db credentials written in a file on the compute node? If so, isn't having hacked root (or nova) access to a compute node already game-over? What are we trying to secure here? If that's what I'm thinking (ie: some VM code to escape from guest, and potentially the hacker can gain access to the db), then IMO that's not the way to enforce things. It's not the role of upstream Nova to do this apart from a well enough written documentation. Cheers, Thomas Goirand (zigo) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.urdin at binero.com Mon Nov 23 23:16:34 2020 From: tobias.urdin at binero.com (Tobias Urdin) Date: Mon, 23 Nov 2020 23:16:34 +0000 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: <6feed46a-c1b8-74ac-f59a-d45b2bfefd67@debian.org> <4b2eb7c4b98846628e1d1e8e389ccc5f@binero.com> <0a5ae0ef-463c-3691-60a2-fc6d85520c23@debian.org> <7EW8KQ.UNB9NASIF2Q11@est.tech>, Message-ID: <6c4ce75dc2414c668a388f5d86de6fcf@binero.com> Hello, This is very true and good feedback, something that nags me everytime I think about it. Having a shared storage and using rbd images backend and still needing SSH between compute nodes. I'm hoping to have some time helping out to clear that up in the libvirt driver. Best regards ________________________________ From: Thomas Goirand Sent: Monday, November 23, 2020 1:21:14 PM To: openstack maillist Subject: Re: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service On 11/23/20 11:42 AM, Balázs Gibizer wrote: > > > On Mon, Nov 23, 2020 at 11:18, Thomas Goirand wrote: >> On 11/23/20 9:30 AM, Tobias Urdin wrote: >>> Hello, >>> >>> >>> Just to clarify that this is already possible when using >>> puppet-nova, it's up to the deployment to >>> >>> make sure the database parameters for the classes is set. >>> >>> >>> We've been running without database credentials in nova.conf on our >>> compute nodes for years. >>> >>> >>> Best regards >>> >>> Tobias >> >> Hi Tobias, >> >> That's not what I'm suggesting. >> >> I'm suggesting that nova-compute code from upstream simply ignores >> completely anything related to db connection, so we're done with the >> topic. That is, if nova-compute process having access to the db is the >> issue we're trying to fix. >> >> Or is it that the security problem is having the db credentials written >> in a file on the compute node? If so, isn't having hacked root (or nova) >> access to a compute node already game-over? >> >> What are we trying to secure here? If that's what I'm thinking (ie: some >> VM code to escape from guest, and potentially the hacker can gain access >> to the db), then IMO that's not the way to enforce things. It's not the >> role of upstream Nova to do this apart from a well enough written >> documentation. > > I always understood this as having a goal to limit the attack surface. > So if a VM escapes out of the sandbox and access the hypervisor then > limit how may other services get compromised outside of the compromised > compute host. > > Cheers, > gibi In general, I would agree with this. However, because of the way cold migrations are working, nova compute boxes are authenticated between each other through ssh. You'd be limiting access to the db, but someone with nova or root ssh access could destroy all compute nodes. So, like it or not, it's game-over anyways. If you want to fix things, make it so that Nova doesn't require such ssh authentication anymore, because that's more urgent, *THEN* we can revisit this topic. Cheers, Thomas Goirand (zigo) -------------- next part -------------- An HTML attachment was scrubbed... URL: From zigo at debian.org Mon Nov 23 23:25:48 2020 From: zigo at debian.org (Thomas Goirand) Date: Tue, 24 Nov 2020 00:25:48 +0100 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: <2a9f8c7b22322b2ed5742628a0c73aa421da358d.camel@redhat.com> References: <6feed46a-c1b8-74ac-f59a-d45b2bfefd67@debian.org> <4b2eb7c4b98846628e1d1e8e389ccc5f@binero.com> <0a5ae0ef-463c-3691-60a2-fc6d85520c23@debian.org> <7EW8KQ.UNB9NASIF2Q11@est.tech> <0a119ba3-707b-057a-a2a9-d515fbb96c3a@debian.org> <2a9f8c7b22322b2ed5742628a0c73aa421da358d.camel@redhat.com> Message-ID: <077272b7-f2a8-c083-979f-9f020b970599@debian.org> On 11/23/20 7:21 PM, Sean Mooney wrote: > On Mon, 2020-11-23 at 18:34 +0100, Thomas Goirand wrote: >> Hi Sean, >> >> Thanks for your post. >> >> On 11/23/20 2:32 PM, Sean Mooney wrote: >>> nova need to enforce it as we use the absense or present of the db creads to know >>> if common code is running in the compute agent or in controller services >> >> I'm a bit shocked to read what I've read in this thread, about the >> double-guess that Nova is doing. >> >> The way the Nova team has been describing, this really looks like hacks >> to hide the internals of Nova, and what the team is asking, is more >> band-aid for it. Probably things have been done this way to make it >> easier for the users, but at this point, it feels like we shouldn't >> attempt to hide facts anymore, and try to have everything explicit, >> which is going the opposite way of what you describe. >> >> Why don't we go the other way around, and get things like a >> superconductor=true configuration directive, for example? > this would break upgrades for everyone one of our upgrade constratins > is you should never have to update your config as part of an upgrade. There's one way to avoid this. Have 3 values for the config option: - None: keep old behavior (that would be the default) - superconductor - cellconductor > where config changes are needed we always give you at least 1 cycle to update > your configs as part of a seperate maintance window. What I'm proposing just above hopefully addresses your concern. > it would also force all deployment tools and packages to chagne as we would have > new portentially incompatible options in config files. There's no problem on the packaging level. Though truth, there would be some work on the config management modules, but that's what they are for. > spcificlly packagers would have to ship different nova config file for supper conductors and cell conductors for that usecase. Simply put: no. In Debian, we could even provide a debconf prompt to address the question (I believe I would do that...). Currently, I don't know any OS that is taking care of doing config file updates anyway. That's something I've been thinking of for a long time, though it's not an easy thing to write (in a shell script), and everyone uses config management systems anyways. >> On 11/23/20 2:32 PM, Sean Mooney wrote: >>> it is a bug to have the db cred in the set fo configs passed to >>> nova-comptue and it has been for years. >> >> In such case, detect that it's the nova-compute agent that's running, >> detect that it has access to db creds, and either: >> - display a big warning (I would prefer that) >> - display an error and quit (maybe bad in the case of an all-in-one setup) >> >> This is orthogonal to the fact that Nova code is doing a hack (which >> should be fixed) to check which daemon is currently running in what mode. > it is not a hack, checking the binary name would be a hack as that is common code > that shoudl be independnt of what name you give the file on disk. Right, it shouldn't be based on the filename on disk, but there are many other ways to implement this. Gibi wrote about having a global CONF value, that would work. Passing additional parameters to the part of the code that connects (or not) to the db would be another way (but probably harder to implement). >> On 11/23/20 2:32 PM, Sean Mooney wrote: >>> we could make this just a ERROR log without the hard fail but that >>> would still not change the fact there is a bug in packages or >>> deployment tools that should be fixed. >> >> Probably. But that shouldn't be upstream author's business on how things >> are deployed. IMO, in the case of an all-in-one, nova-compute should >> continue to work and just ignore the db params, and at worse display a >> huge warning on the logs. > well there i dissagree the warning/error message is the bare minium we should do > and at most we should allow ti to contiue executing and optimally it should stop the service sicne we know > the config is invalid. Worst case, this disagreement could be solved by a configuration value, on by default if you like: die_if_nova_compute_has_db_access=True :) I believe everyone will agree that it's super easy to change such a config value if you want to deploy all-in-one, and it's probably not much to ask to someone deploying in a non-standard way. Cheers, Thomas Goirand (zigo) From dtantsur at redhat.com Tue Nov 24 10:54:55 2020 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Tue, 24 Nov 2020 11:54:55 +0100 Subject: [ironic] [infra] Making Glean work with IPA for static IP assignment Message-ID: Hi Ian, Given our timezone difference, I've decided to send you an email, adding openstack-discuss in CC for greater exposure. We're trying to make IPA (our agent ramdisk) to work without relying on DHCP for cases like Edge deployments. We've settled on the network_data.json format for the API side and wanted to use Glean on the ramdisk to apply it. You can read more details in [1]. The problem is, I cannot make Glean work with any ramdisk I build. The crux of the problem seems to be that NetworkManager (used by default in RHEL, CentOS, Fedora and Debian at least) starts very early, creates the default connection and ignores whatever files Glean happens to write afterwards. On Debian running `systemctl restart networking` actually helped to pick the new configuration, but I'm not sure we want to do that in Glean. I haven't been able to make NetworkManager pick up the changes on RH systems so far. I build ramdisks using IPA-builder [2] by adding the simple-init element. I've tried removing dhcp-all-interfaces (which we depend on by default) to no effect. I've tried disabling the DHCP server, ended up with no IP connectivity at all. I haven't tried to shutdown and restart a connection as recommended in [3] since it's not trivial to do via SSH. Do you maybe have any hints how to proceed? I'd be curious to know how static IP assignment works in the infra setup. Do you have images with NetworkManager there? Do you use the simple-init element? Any help is very appreciated. Dmitry [1] https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/L3-based-deployment.html [2] https://opendev.org/openstack/ironic-python-agent-builder [3] https://mail.gnome.org/archives/networkmanager-list/2014-January/msg00032.html -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosmaita.fossdev at gmail.com Tue Nov 24 13:32:51 2020 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Tue, 24 Nov 2020 08:32:51 -0500 Subject: [cinder] this week's meeting in video+IRC Message-ID: <7d30d6b3-b26d-b99b-12e9-6b77cff4b768@gmail.com> Quick reminder that this week's Cinder team meeting on Wednesday 25 November, being the final meeting of the month, will be held in both videoconference and IRC at the regularly scheduled time of 1400 UTC. Here's a quick reminder of the video meeting rules we've agreed to: * Everyone will keep IRC open during the meeting. * We'll take notes in IRC to leave a record similar to what we have for our regular IRC meetings. * Some people are more comfortable communicating in written English. So at any point, any attendee may request that the discussion of the current topic be conducted entirely in IRC. connection info: https://bluejeans.com/3228528973 cheers, brian From juliaashleykreger at gmail.com Tue Nov 24 15:02:44 2020 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Tue, 24 Nov 2020 07:02:44 -0800 Subject: [ironic] Proposing Steve Baker (stevebaker) for ironic-core Message-ID: Greetings everyone, I would like to propose Steve Baker for ironic-core. Steve shifted into focusing on Ironic contribution this year and he has been actively reviewing changes during the Victoria and now Wallaby cycle. He has brought insight, drive, and a curiosity to ask questions. Plus he took on the challenge of removing wsme from Ironic's API which is no small feat. I've run this nomination past the existing cores and everyone responded in full support of doing so. So if there are no objections, I'll add Steve to ironic-core next week. Otherwise, Congratulations Steve! -Julia From jay.faulkner at verizonmedia.com Tue Nov 24 15:14:06 2020 From: jay.faulkner at verizonmedia.com (Jay Faulkner) Date: Tue, 24 Nov 2020 07:14:06 -0800 Subject: [E] [ironic] Proposing Steve Baker (stevebaker) for ironic-core In-Reply-To: References: Message-ID: Congratulations, Steve! - Jay Faulkner On Tue, Nov 24, 2020 at 7:10 AM Julia Kreger wrote: > Greetings everyone, > > I would like to propose Steve Baker for ironic-core. Steve shifted > into focusing on Ironic contribution this year and he has been > actively reviewing changes during the Victoria and now Wallaby cycle. > He has brought insight, drive, and a curiosity to ask questions. Plus > he took on the challenge of removing wsme from Ironic's API which is > no small feat. > > I've run this nomination past the existing cores and everyone > responded in full support of doing so. > > So if there are no objections, I'll add Steve to ironic-core next week. > > Otherwise, Congratulations Steve! > > -Julia > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mcginnis at gmx.com Tue Nov 24 15:39:51 2020 From: sean.mcginnis at gmx.com (Sean McGinnis) Date: Tue, 24 Nov 2020 09:39:51 -0600 Subject: [all] X Release Naming In-Reply-To: <20201102145344.GA1505236@sm-workstation> References: <20201102145344.GA1505236@sm-workstation> Message-ID: Hey everyone, Just a reminder that we will be wrapping up community input for name suggestions this Thursday at 12:59:59 UTC. There are a lot more (and some really good) X name suggestions collected on the wiki page than I thought we would get. But if you have any other ideas to add, please get them added to the page in the next couple of days. Thanks! Sean On 11/2/20 8:53 AM, Sean McGinnis wrote: > Hello everyone, > > This is to notify everyone that we are now kicking off the release naming > process for the 'X' OpenStack release. > > Starting with the last W naming, we had altered our traditional way of choosing > a release name to allow any name that meets the basic criteria - basically that > the name begins with the chosen letter, it is made up if the ISO basic Latin > alphabet, and that it is 10 characters or less in length. > > Community proposed names are collected on the wiki page for the X Release > Naming. This page also includes more details about the process and timing: > > https://wiki.openstack.org/wiki/Release_Naming/X_Proposals > > We welcome any names from the community. This should be an intersting release > to see what everyone comes up with! Please add any ideas to the wiki page. > > -- > Sean McGinnis > From hberaud at redhat.com Tue Nov 24 17:37:04 2020 From: hberaud at redhat.com (Herve Beraud) Date: Tue, 24 Nov 2020 18:37:04 +0100 Subject: [release][infra[PTL] SSH key error - RedFlag stop approving In-Reply-To: References: Message-ID: Just a quick reminder of the current state of the openstack release management. We are stuck by the SSH issue and we stopped approving release by waiting to fix all elements of the problem. Three patches are on the rails to solve the issue, however one isn't yet merged: - https://review.opendev.org/c/openstack/project-config/+/763797/ (merged) - https://review.opendev.org/c/openstack/project-config/+/763830/ (merged) - https://review.opendev.org/c/zuul/zuul-jobs/+/763834/ (not merged) We are stopping approving releases until this issue isn't resolved. When all these patches will be merged we will try to re-enqueue our failing ref to observe if it solves our issue and we will decide if we can restart approving releases. I added the PTLs to the object of this thread to inform them about that and also so that they are not surprised that we do not approve their release patches. We will communicate as soon as we will restart approving release patches. Thanks for your comprehension. Le lun. 23 nov. 2020 à 12:49, Herve Beraud a écrit : > Hello, > > We are facing SSH issues on our release jobs [1][2]. > Indeed, our release account failed to connect to gerrit through SSH [2]. > The ID seems to be recognized when we try it. > So that would probably mean we have a stale host key on the machine the script is running on . > > We suppose that the issue could be a side effect of the gerrit upgrade, we updated the etherpad to inform the infra team [3] > > @release managers: We should stop approving, so, please hold all our unmerged patches while this incident isn't solved. > > Thanks for your reading, > > [1] > http://lists.openstack.org/pipermail/release-job-failures/2020-November/001487.html[2] > Example of faced error: > ``` > ssh://release at review.opendev.org:29418/openstack/python-senlinclient.git > did not work. Description: Host key verification failed. > Could not read from remote repository > ``` > [3] https://etherpad.opendev.org/p/gerrit-3.2-post-upgrade-notes > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtreinish at kortar.org Tue Nov 24 18:58:47 2020 From: mtreinish at kortar.org (Matthew Treinish) Date: Tue, 24 Nov 2020 13:58:47 -0500 Subject: [qa][tempest] Update language in tempest code base In-Reply-To: <173348b1df7.b5898c11633886.9175405555090897907@ghanshyammann.com> References: <173344b91ec.122943da3630997.4524106110681904507@ghanshyammann.com> <2383106.3VsfAaAtOV@whitebase.usersys.redhat.com> <173348b1df7.b5898c11633886.9175405555090897907@ghanshyammann.com> Message-ID: On Thu, Jul 09, 2020 at 12:06:39PM -0500, Ghanshyam Mann wrote: > ---- On Thu, 09 Jul 2020 11:45:19 -0500 Arx Cruz wrote ---- > > Yes, that's the idea. > > We can keep the old interface for a few cycles, with warning deprecation message advertising to use the new one, and then remove in the future. > > Deprecating things leads to two situations which really need some good reason before doing it: > > - If we keep the deprecated interfaces working along with new interfaces then it is confusion for users > as well as maintenance effort. In my experience, very less migration happen to new things if old keep working. Just a heads up the recent stestr 3.1.0 release (https://github.com/mtreinish/stestr/releases/tag/3.1.0) did this first step and deprecated things with: https://github.com/mtreinish/stestr/pull/297 There were multiple recent user requests to start this process sooner rather than later. So regardless of what timetable and decision we make for tempest's interfaces we should probably update tempest's internal stestr api usage to reflect the new interface sooner rather than later (it will require bumping the min stestr version to 3.1.0 when that change is made). > - If we remove them in future then it is breaking change. For stestr my plan is to make this breaking change eventually as part of 4.0.0 release. The exact timetable for that I'm not clear on yet since we try to avoid making breaking changes. The previous 2 backwards incompatible changes were removing python 2 support (which was 3.0.0) and switching to cliff for the cli, which wasn't strictly backwards incompatible we just made it 2.0.0 as a precaution because there were potential edge cases with cliff we were worried about. So there really isn't a established pattern for this kind of deprecation removal. I don't expect it to be a quick process though. -Matt Treinish > IMO, we need to first ask/analyse whether name changes are worth to do with above things as results. Or in other > team we should first define what is 'outdated naming conventions' and how worth to fix those. > > -gmann > > > > Kind regards, > > > > On Thu, Jul 9, 2020 at 6:15 PM Luigi Toscano wrote: > > > > > > -- > > Arx Cruz > > Software Engineer > > Red Hat EMEA > > arxcruz at redhat.com > > @RedHat Red Hat Red Hat > > On Thursday, 9 July 2020 17:57:14 CEST Ghanshyam Mann wrote: > > > ---- On Thu, 09 Jul 2020 10:14:58 -0500 Arx Cruz wrote > > > ---- > > > > Hello, > > > > I would like to start a discussion regarding the topic. > > > > At this moment in time we have an opportunity to be a more open and > > > > inclusive project by eliminating outdated naming conventions from > > > > tempest codebase, such as blacklist, whitelist.We should take the > > > > opportunity and do our best to replace outdated terms with their more > > > > inclusive alternatives.As you can see in [1] the TripleO project is > > > > already working on this initiative, and I would like to work on this as > > > > well on the tempest side. > > > Thanks Arx for raising it. > > > > > > I always have hard time to understand the definition of 'outdated naming > > > conventions ' are they outdated from coding language perspective or > > > outdated as English language perspective? I do not see naming used in > > > coding language should be matched with English as grammar/outdated/new > > > style language. As long as they are not so bad (hurt anyone culture, > > > abusing word etc) it is fine to keep them as it is and start adopting new > > > names for new things we code. > > > > > > For me, naming convention are the things which always can be improved over > > > time, none of the name is best suited for everyone in open source. But we > > > need to understand whether it is worth to do in term of 1. effort of > > > changing those 2. un- comfortness of adopting new names 3. again changing > > > in future. > > > > > > At least from Tempest perspective, blacklist is very known common word used > > > for lot of interfaces and dependent testing tool. I cannot debate on how > > > good it is or bad but i can debate on not-worth to change now. For new > > > interface, we can always use best-suggested name as per that > > > time/culture/maintainers. We have tried few of such improvement in past but > > > end up not-successful. Example: - > > > https://opendev.org/openstack/tempest/src/commit/e1eebfa8451d4c28bef0669e4a > > > 7f493b6086cab9/tempest/test.py#L43 > > > > > > > That's not the only used terminology for list of things, though. We could > > always add new interfaces and keep the old ones are deprecated (but not > > advertised) for the foreseable future. The old code won't be broken and the > > new one would use the new terminology, I'd say it's a good solution. > > > > > > -- > > Luigi > > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From gmann at ghanshyammann.com Tue Nov 24 19:49:33 2020 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 24 Nov 2020 13:49:33 -0600 Subject: [qa][tempest] Update language in tempest code base In-Reply-To: References: <173344b91ec.122943da3630997.4524106110681904507@ghanshyammann.com> <2383106.3VsfAaAtOV@whitebase.usersys.redhat.com> <173348b1df7.b5898c11633886.9175405555090897907@ghanshyammann.com> Message-ID: <175fbcdda1f.11b0cc28f634324.3835419687523632284@ghanshyammann.com> ---- On Tue, 24 Nov 2020 12:58:47 -0600 Matthew Treinish wrote ---- > On Thu, Jul 09, 2020 at 12:06:39PM -0500, Ghanshyam Mann wrote: > > ---- On Thu, 09 Jul 2020 11:45:19 -0500 Arx Cruz wrote ---- > > > Yes, that's the idea. > > > We can keep the old interface for a few cycles, with warning deprecation message advertising to use the new one, and then remove in the future. > > > > Deprecating things leads to two situations which really need some good reason before doing it: > > > > - If we keep the deprecated interfaces working along with new interfaces then it is confusion for users > > as well as maintenance effort. In my experience, very less migration happen to new things if old keep working. > > Just a heads up the recent stestr 3.1.0 release > (https://github.com/mtreinish/stestr/releases/tag/3.1.0) did this first step > and deprecated things with: > > https://github.com/mtreinish/stestr/pull/297 > > There were multiple recent user requests to start this process sooner rather > than later. So regardless of what timetable and decision we make for tempest's > interfaces we should probably update tempest's internal stestr api usage to > reflect the new interface sooner rather than later (it will require bumping the > min stestr version to 3.1.0 when that change is made). > > > - If we remove them in future then it is breaking change. > > For stestr my plan is to make this breaking change eventually as part of 4.0.0 > release. The exact timetable for that I'm not clear on yet since we try to avoid > making breaking changes. The previous 2 backwards incompatible changes were > removing python 2 support (which was 3.0.0) and switching to cliff for the cli, > which wasn't strictly backwards incompatible we just made it 2.0.0 as a > precaution because there were potential edge cases with cliff we were worried > about. So there really isn't a established pattern for this kind of deprecation > removal. I don't expect it to be a quick process though. Thanks matt for the updates and providing new interfaces in stestr, It will surely help Tempest to move towards those new deprecate these interface/wording. As discussed in PTG/Forum for overall direction in OpenStack, I am ok to do similar changes in Tempest. For branchless Tempest, as you mentioned we need to bump the min stestr version to 3.1.0 for all supported stable branches which are stein onwards for now. Hope that is fine from a requirement perspective. We can move Tempest to new stestr 3.1.0 soon and project side usage of stestr in unit/functional tests runner is also not much. Seems only two repo: - https://codesearch.opendev.org/?q=stestr%20run%20--black&i=nope&files=tox.ini&excludeFiles=&repos= -gmann > > > -Matt Treinish > > > IMO, we need to first ask/analyse whether name changes are worth to do with above things as results. Or in other > > team we should first define what is 'outdated naming conventions' and how worth to fix those. > > > > -gmann > > > > > > > Kind regards, > > > > > > On Thu, Jul 9, 2020 at 6:15 PM Luigi Toscano wrote: > > > > > > > > > -- > > > Arx Cruz > > > Software Engineer > > > Red Hat EMEA > > > arxcruz at redhat.com > > > @RedHat Red Hat Red Hat > > > On Thursday, 9 July 2020 17:57:14 CEST Ghanshyam Mann wrote: > > > > ---- On Thu, 09 Jul 2020 10:14:58 -0500 Arx Cruz wrote > > > > ---- > > > > > Hello, > > > > > I would like to start a discussion regarding the topic. > > > > > At this moment in time we have an opportunity to be a more open and > > > > > inclusive project by eliminating outdated naming conventions from > > > > > tempest codebase, such as blacklist, whitelist.We should take the > > > > > opportunity and do our best to replace outdated terms with their more > > > > > inclusive alternatives.As you can see in [1] the TripleO project is > > > > > already working on this initiative, and I would like to work on this as > > > > > well on the tempest side. > > > > Thanks Arx for raising it. > > > > > > > > I always have hard time to understand the definition of 'outdated naming > > > > conventions ' are they outdated from coding language perspective or > > > > outdated as English language perspective? I do not see naming used in > > > > coding language should be matched with English as grammar/outdated/new > > > > style language. As long as they are not so bad (hurt anyone culture, > > > > abusing word etc) it is fine to keep them as it is and start adopting new > > > > names for new things we code. > > > > > > > > For me, naming convention are the things which always can be improved over > > > > time, none of the name is best suited for everyone in open source. But we > > > > need to understand whether it is worth to do in term of 1. effort of > > > > changing those 2. un- comfortness of adopting new names 3. again changing > > > > in future. > > > > > > > > At least from Tempest perspective, blacklist is very known common word used > > > > for lot of interfaces and dependent testing tool. I cannot debate on how > > > > good it is or bad but i can debate on not-worth to change now. For new > > > > interface, we can always use best-suggested name as per that > > > > time/culture/maintainers. We have tried few of such improvement in past but > > > > end up not-successful. Example: - > > > > https://opendev.org/openstack/tempest/src/commit/e1eebfa8451d4c28bef0669e4a > > > > 7f493b6086cab9/tempest/test.py#L43 > > > > > > > > > > That's not the only used terminology for list of things, though. We could > > > always add new interfaces and keep the old ones are deprecated (but not > > > advertised) for the foreseable future. The old code won't be broken and the > > > new one would use the new terminology, I'd say it's a good solution. > > > > > > > > > -- > > > Luigi > > > > > > > > > > > > From skaplons at redhat.com Tue Nov 24 21:58:31 2020 From: skaplons at redhat.com (Slawek Kaplonski) Date: Tue, 24 Nov 2020 22:58:31 +0100 Subject: [neutron][operators][all] Watch out for updates of stable/train and stable/stein releases in Neutron Message-ID: <20201124215831.bryboz64jypo75eq@p1.localdomain> Hi, I want to warn all of You about terrible mistake which we made in Neutron some time ago. We backported to stable releases patch [1] which broke update workflow. So if You are now updating Your Stein or Train Neutron to latest version and You will do it as it should be done, so first neutron-server and then agents, Your neutron-ovs-agents will not work properly with newer neutron-server. Details are in reported bug [2] Broken versions are: * for Train 15.2.0 and 15.3.0 * for Stein 14.3.1, 14.4.0 and 14.4.1 We proposed reverts of [1] and those reverts are now in gate. As soon as they will be merged we will release new, fixed versions for both Stein and Train. So if You didn't update to those broken versions yet, please don't do it now and wait for next version with fix. If You already updated and fixed that issue on Your clusters - You will have exactly same problem during next update again. I know it's very bad but unfortunately we don't have any other way to fix that issue. [1] https://review.opendev.org/#/c/744133/ [2] https://bugs.launchpad.net/neutron/+bug/1903531 -- Slawek Kaplonski Principal Software Engineer Red Hat From eandersson at blizzard.com Tue Nov 24 22:37:45 2020 From: eandersson at blizzard.com (Erik Olof Gunnar Andersson) Date: Tue, 24 Nov 2020 22:37:45 +0000 Subject: [neutron][operators][all] Watch out for updates of stable/train and stable/stein releases in Neutron In-Reply-To: <20201124215831.bryboz64jypo75eq@p1.localdomain> References: <20201124215831.bryboz64jypo75eq@p1.localdomain> Message-ID: Does this affect Queens / Rocky as well? I saw that they got a patch related to this reverted a few days ago. Best Regards, Erik Olof Gunnar Andersson Technical Lead, Senior Cloud Engineer -----Original Message----- From: Slawek Kaplonski Sent: Tuesday, November 24, 2020 1:59 PM To: openstack-discuss at lists.openstack.org Subject: [neutron][operators][all] Watch out for updates of stable/train and stable/stein releases in Neutron Hi, I want to warn all of You about terrible mistake which we made in Neutron some time ago. We backported to stable releases patch [1] which broke update workflow. So if You are now updating Your Stein or Train Neutron to latest version and You will do it as it should be done, so first neutron-server and then agents, Your neutron-ovs-agents will not work properly with newer neutron-server. Details are in reported bug [2] Broken versions are: * for Train 15.2.0 and 15.3.0 * for Stein 14.3.1, 14.4.0 and 14.4.1 We proposed reverts of [1] and those reverts are now in gate. As soon as they will be merged we will release new, fixed versions for both Stein and Train. So if You didn't update to those broken versions yet, please don't do it now and wait for next version with fix. If You already updated and fixed that issue on Your clusters - You will have exactly same problem during next update again. I know it's very bad but unfortunately we don't have any other way to fix that issue. [1] https://urldefense.com/v3/__https://review.opendev.org/*/c/744133/__;Iw!!Ci6f514n9QsL8ck!15u_iIzQ-cPwno7OIj7ytuTQCHm8gkq6RnVO5dEhZqonxFOz-Brbri7Ly_T4RxwbZA$ [2] https://urldefense.com/v3/__https://bugs.launchpad.net/neutron/*bug/1903531__;Kw!!Ci6f514n9QsL8ck!15u_iIzQ-cPwno7OIj7ytuTQCHm8gkq6RnVO5dEhZqonxFOz-Brbri7Ly_T6u2Bf9w$ -- Slawek Kaplonski Principal Software Engineer Red Hat From skaplons at redhat.com Tue Nov 24 22:53:55 2020 From: skaplons at redhat.com (Slawek Kaplonski) Date: Tue, 24 Nov 2020 23:53:55 +0100 Subject: [neutron][operators][all] Watch out for updates of stable/train and stable/stein releases in Neutron In-Reply-To: References: <20201124215831.bryboz64jypo75eq@p1.localdomain> Message-ID: <20201124225355.b7ft46d326dlwpzs@p1.localdomain> Hi, On Tue, Nov 24, 2020 at 10:37:45PM +0000, Erik Olof Gunnar Andersson wrote: > Does this affect Queens / Rocky as well? I saw that they got a patch related to this reverted a few days ago. Yes, this affects Queens/Rocky too but in case of those branches, this bad patch wasn't included in any release as both are in EM phase for long time already. So that's why I forgot to mention about them in the previous email. Thx for mentioning them too :) > > Best Regards, Erik Olof Gunnar Andersson > Technical Lead, Senior Cloud Engineer > > -----Original Message----- > From: Slawek Kaplonski > Sent: Tuesday, November 24, 2020 1:59 PM > To: openstack-discuss at lists.openstack.org > Subject: [neutron][operators][all] Watch out for updates of stable/train and stable/stein releases in Neutron > > Hi, > > I want to warn all of You about terrible mistake which we made in Neutron some time ago. > We backported to stable releases patch [1] which broke update workflow. So if You are now updating Your Stein or Train Neutron to latest version and You will do it as it should be done, so first neutron-server and then agents, Your neutron-ovs-agents will not work properly with newer neutron-server. > Details are in reported bug [2] > > Broken versions are: > * for Train 15.2.0 and 15.3.0 > * for Stein 14.3.1, 14.4.0 and 14.4.1 > > We proposed reverts of [1] and those reverts are now in gate. As soon as they will be merged we will release new, fixed versions for both Stein and Train. > So if You didn't update to those broken versions yet, please don't do it now and wait for next version with fix. > > If You already updated and fixed that issue on Your clusters - You will have exactly same problem during next update again. I know it's very bad but unfortunately we don't have any other way to fix that issue. > > [1] https://urldefense.com/v3/__https://review.opendev.org/*/c/744133/__;Iw!!Ci6f514n9QsL8ck!15u_iIzQ-cPwno7OIj7ytuTQCHm8gkq6RnVO5dEhZqonxFOz-Brbri7Ly_T4RxwbZA$ > [2] https://urldefense.com/v3/__https://bugs.launchpad.net/neutron/*bug/1903531__;Kw!!Ci6f514n9QsL8ck!15u_iIzQ-cPwno7OIj7ytuTQCHm8gkq6RnVO5dEhZqonxFOz-Brbri7Ly_T6u2Bf9w$ > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat > > > -- Slawek Kaplonski Principal Software Engineer Red Hat From iwienand at redhat.com Wed Nov 25 02:09:01 2020 From: iwienand at redhat.com (Ian Wienand) Date: Wed, 25 Nov 2020 13:09:01 +1100 Subject: [ironic] [infra] Making Glean work with IPA for static IP assignment In-Reply-To: References: Message-ID: <20201125020901.GA522326@fedora19.localdomain> On Tue, Nov 24, 2020 at 11:54:55AM +0100, Dmitry Tantsur wrote: > The problem is, I cannot make Glean work with any ramdisk I build. The crux > of the problem seems to be that NetworkManager (used by default in RHEL, > CentOS, Fedora and Debian at least) starts very early, creates the default > connection and ignores whatever files Glean happens to write afterwards. On > Debian running `systemctl restart networking` actually helped to pick the > new configuration, but I'm not sure we want to do that in Glean. I haven't > been able to make NetworkManager pick up the changes on RH systems so far. So we do use NetworkManager in the OpenDev images, and we do not see NetworkManager starting before glean. The way it should work is that simple-init in dib installs glean to the image. That runs the glean install script (use --use-nm argument if DIB_SIMPLE_INIT_NETWORKMANAGER, which is default on centos/fedora) which installs two things; udev rules and a systemd handler. The udev is pretty simple [1] and should add a "Wants" for each net device; e.g. eth1 would match and create a Wants glean at eth1.service, which then matches [2] which should write out the ifcfg config file. After this, NetworkManager should start, notice the config file for the interface and bring it up. > Do you maybe have any hints how to proceed? I'd be curious to know how > static IP assignment works in the infra setup. Do you have images with > NetworkManager there? Do you use the simple-init element? As noted yes we use this. Really only in two contexts; it's Rackspace that doesn't have DHCP so we have to setup the interface statically from the configdrive data. Other clouds all provide DHCP, which is used when there's no configdrive data. Here is a systemd-analyze from one of our Centos nodes if it helps: graphical.target @18.403s └─multi-user.target @18.403s └─unbound.service @5.467s +12.934s └─network.target @5.454s └─NetworkManager.service @5.339s +112ms └─network-pre.target @5.334s └─glean at ens3.service @4.227s +1.102s └─basic.target @4.167s └─sockets.target @4.166s └─iscsiuio.socket @4.165s └─sysinit.target @4.153s └─systemd-udev-settle.service @1.905s +2.245s └─systemd-udev-trigger.service @1.242s +659ms └─systemd-udevd-control.socket @1.239s └─system.slice At a guess; I feel like the udev bits are probably not happening correctly in your case? That's important to get the glean@ service in the chain to pre-create the config file -i [1] https://opendev.org/opendev/glean/src/branch/master/glean/init/glean-udev.rules [2] https://opendev.org/opendev/glean/src/branch/master/glean/init/glean-nm at .service From gmann at ghanshyammann.com Wed Nov 25 04:22:32 2020 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 24 Nov 2020 22:22:32 -0600 Subject: [qa][cinder][glance][swift] Gate status for swift test failing Bug#1905432 Message-ID: <175fda38292.ed631f76640129.5700959767027160091@ghanshyammann.com> Hello Everyone, As you have seen that test_create_object_with_transfer_encoding is failing consistently since 20th Nov which is failing integrated-gate-storage and integrated-gate-object-storage jobs. The issue is that Tempest is getting 500 from swift API, I could not find the root cause yet so decided to disable this test for now to unlock the gate. Avoid recheck for this failure until this is merge - https://review.opendev.org/c/openstack/tempest/+/764061 I have filled bug against Tempest and Swift to track it - https://bugs.launchpad.net/swift/+bug/1905432 -gmann From tobias.urdin at binero.com Wed Nov 25 08:47:03 2020 From: tobias.urdin at binero.com (Tobias Urdin) Date: Wed, 25 Nov 2020 08:47:03 +0000 Subject: [neutron][operators][all] Watch out for updates of stable/train and stable/stein releases in Neutron In-Reply-To: <20201124225355.b7ft46d326dlwpzs@p1.localdomain> References: <20201124215831.bryboz64jypo75eq@p1.localdomain> , <20201124225355.b7ft46d326dlwpzs@p1.localdomain> Message-ID: Hello, So to be clear in our case here, we are running 15.1.0 for neutron-server and 15.3.0 for neutron agents. That means that the agents does work but there is a security issue,as described regarding allowed address-pair, have I understood it correctly? Best regards Tobias ________________________________ From: Slawek Kaplonski Sent: Tuesday, November 24, 2020 11:53:55 PM To: Erik Olof Gunnar Andersson Cc: openstack-discuss at lists.openstack.org Subject: Re: [neutron][operators][all] Watch out for updates of stable/train and stable/stein releases in Neutron Hi, On Tue, Nov 24, 2020 at 10:37:45PM +0000, Erik Olof Gunnar Andersson wrote: > Does this affect Queens / Rocky as well? I saw that they got a patch related to this reverted a few days ago. Yes, this affects Queens/Rocky too but in case of those branches, this bad patch wasn't included in any release as both are in EM phase for long time already. So that's why I forgot to mention about them in the previous email. Thx for mentioning them too :) > > Best Regards, Erik Olof Gunnar Andersson > Technical Lead, Senior Cloud Engineer > > -----Original Message----- > From: Slawek Kaplonski > Sent: Tuesday, November 24, 2020 1:59 PM > To: openstack-discuss at lists.openstack.org > Subject: [neutron][operators][all] Watch out for updates of stable/train and stable/stein releases in Neutron > > Hi, > > I want to warn all of You about terrible mistake which we made in Neutron some time ago. > We backported to stable releases patch [1] which broke update workflow. So if You are now updating Your Stein or Train Neutron to latest version and You will do it as it should be done, so first neutron-server and then agents, Your neutron-ovs-agents will not work properly with newer neutron-server. > Details are in reported bug [2] > > Broken versions are: > * for Train 15.2.0 and 15.3.0 > * for Stein 14.3.1, 14.4.0 and 14.4.1 > > We proposed reverts of [1] and those reverts are now in gate. As soon as they will be merged we will release new, fixed versions for both Stein and Train. > So if You didn't update to those broken versions yet, please don't do it now and wait for next version with fix. > > If You already updated and fixed that issue on Your clusters - You will have exactly same problem during next update again. I know it's very bad but unfortunately we don't have any other way to fix that issue. > > [1] https://urldefense.com/v3/__https://review.opendev.org/*/c/744133/__;Iw!!Ci6f514n9QsL8ck!15u_iIzQ-cPwno7OIj7ytuTQCHm8gkq6RnVO5dEhZqonxFOz-Brbri7Ly_T4RxwbZA$ > [2] https://urldefense.com/v3/__https://bugs.launchpad.net/neutron/*bug/1903531__;Kw!!Ci6f514n9QsL8ck!15u_iIzQ-cPwno7OIj7ytuTQCHm8gkq6RnVO5dEhZqonxFOz-Brbri7Ly_T6u2Bf9w$ > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat > > > -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Wed Nov 25 08:58:23 2020 From: skaplons at redhat.com (Slawek Kaplonski) Date: Wed, 25 Nov 2020 09:58:23 +0100 Subject: [neutron][operators][all] Watch out for updates of stable/train and stable/stein releases in Neutron In-Reply-To: References: <20201124215831.bryboz64jypo75eq@p1.localdomain> <20201124225355.b7ft46d326dlwpzs@p1.localdomain> Message-ID: <20201125085823.5wdfjn2kf2jnyvah@p1.localdomain> Hi, On Wed, Nov 25, 2020 at 08:47:03AM +0000, Tobias Urdin wrote: > Hello, > > > So to be clear in our case here, we are running 15.1.0 for neutron-server and 15.3.0 for neutron agents. > > That means that the agents does work but there is a security issue,as described regarding allowed address-pair, have I understood it correctly? Yes, as it may have errors while applying SG rules. > > > Best regards > > Tobias > > ________________________________ > From: Slawek Kaplonski > Sent: Tuesday, November 24, 2020 11:53:55 PM > To: Erik Olof Gunnar Andersson > Cc: openstack-discuss at lists.openstack.org > Subject: Re: [neutron][operators][all] Watch out for updates of stable/train and stable/stein releases in Neutron > > Hi, > > On Tue, Nov 24, 2020 at 10:37:45PM +0000, Erik Olof Gunnar Andersson wrote: > > Does this affect Queens / Rocky as well? I saw that they got a patch related to this reverted a few days ago. > > Yes, this affects Queens/Rocky too but in case of those branches, this bad patch > wasn't included in any release as both are in EM phase for long time already. So > that's why I forgot to mention about them in the previous email. > Thx for mentioning them too :) > > > > > Best Regards, Erik Olof Gunnar Andersson > > Technical Lead, Senior Cloud Engineer > > > > -----Original Message----- > > From: Slawek Kaplonski > > Sent: Tuesday, November 24, 2020 1:59 PM > > To: openstack-discuss at lists.openstack.org > > Subject: [neutron][operators][all] Watch out for updates of stable/train and stable/stein releases in Neutron > > > > Hi, > > > > I want to warn all of You about terrible mistake which we made in Neutron some time ago. > > We backported to stable releases patch [1] which broke update workflow. So if You are now updating Your Stein or Train Neutron to latest version and You will do it as it should be done, so first neutron-server and then agents, Your neutron-ovs-agents will not work properly with newer neutron-server. > > Details are in reported bug [2] > > > > Broken versions are: > > * for Train 15.2.0 and 15.3.0 > > * for Stein 14.3.1, 14.4.0 and 14.4.1 > > > > We proposed reverts of [1] and those reverts are now in gate. As soon as they will be merged we will release new, fixed versions for both Stein and Train. > > So if You didn't update to those broken versions yet, please don't do it now and wait for next version with fix. > > > > If You already updated and fixed that issue on Your clusters - You will have exactly same problem during next update again. I know it's very bad but unfortunately we don't have any other way to fix that issue. > > > > [1] https://urldefense.com/v3/__https://review.opendev.org/*/c/744133/__;Iw!!Ci6f514n9QsL8ck!15u_iIzQ-cPwno7OIj7ytuTQCHm8gkq6RnVO5dEhZqonxFOz-Brbri7Ly_T4RxwbZA$ > > [2] https://urldefense.com/v3/__https://bugs.launchpad.net/neutron/*bug/1903531__;Kw!!Ci6f514n9QsL8ck!15u_iIzQ-cPwno7OIj7ytuTQCHm8gkq6RnVO5dEhZqonxFOz-Brbri7Ly_T6u2Bf9w$ > > > > -- > > Slawek Kaplonski > > Principal Software Engineer > > Red Hat > > > > > > > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat > > -- Slawek Kaplonski Principal Software Engineer Red Hat From skaplons at redhat.com Wed Nov 25 09:00:22 2020 From: skaplons at redhat.com (Slawek Kaplonski) Date: Wed, 25 Nov 2020 10:00:22 +0100 Subject: [neutron][operators][all] Watch out for updates of stable/train and stable/stein releases in Neutron In-Reply-To: <20201125085823.5wdfjn2kf2jnyvah@p1.localdomain> References: <20201124215831.bryboz64jypo75eq@p1.localdomain> <20201124225355.b7ft46d326dlwpzs@p1.localdomain> <20201125085823.5wdfjn2kf2jnyvah@p1.localdomain> Message-ID: <20201125090022.4iouend2rxkpkjmg@p1.localdomain> Hi, On Wed, Nov 25, 2020 at 09:58:23AM +0100, Slawek Kaplonski wrote: > Hi, > > On Wed, Nov 25, 2020 at 08:47:03AM +0000, Tobias Urdin wrote: > > Hello, > > > > > > So to be clear in our case here, we are running 15.1.0 for neutron-server and 15.3.0 for neutron agents. > > > > That means that the agents does work but there is a security issue,as described regarding allowed address-pair, have I understood it correctly? > > Yes, as it may have errors while applying SG rules. But one more thing. I'm not really sure if that is security issue TBH. By default neutron is dropping traffic to/from instances and You need to allow some kind of traffic by setting security group rules. So if rules will not be applied, some traffic will be dropped but nothing unwanted shouldn't be allowed. > > > > > > > Best regards > > > > Tobias > > > > ________________________________ > > From: Slawek Kaplonski > > Sent: Tuesday, November 24, 2020 11:53:55 PM > > To: Erik Olof Gunnar Andersson > > Cc: openstack-discuss at lists.openstack.org > > Subject: Re: [neutron][operators][all] Watch out for updates of stable/train and stable/stein releases in Neutron > > > > Hi, > > > > On Tue, Nov 24, 2020 at 10:37:45PM +0000, Erik Olof Gunnar Andersson wrote: > > > Does this affect Queens / Rocky as well? I saw that they got a patch related to this reverted a few days ago. > > > > Yes, this affects Queens/Rocky too but in case of those branches, this bad patch > > wasn't included in any release as both are in EM phase for long time already. So > > that's why I forgot to mention about them in the previous email. > > Thx for mentioning them too :) > > > > > > > > Best Regards, Erik Olof Gunnar Andersson > > > Technical Lead, Senior Cloud Engineer > > > > > > -----Original Message----- > > > From: Slawek Kaplonski > > > Sent: Tuesday, November 24, 2020 1:59 PM > > > To: openstack-discuss at lists.openstack.org > > > Subject: [neutron][operators][all] Watch out for updates of stable/train and stable/stein releases in Neutron > > > > > > Hi, > > > > > > I want to warn all of You about terrible mistake which we made in Neutron some time ago. > > > We backported to stable releases patch [1] which broke update workflow. So if You are now updating Your Stein or Train Neutron to latest version and You will do it as it should be done, so first neutron-server and then agents, Your neutron-ovs-agents will not work properly with newer neutron-server. > > > Details are in reported bug [2] > > > > > > Broken versions are: > > > * for Train 15.2.0 and 15.3.0 > > > * for Stein 14.3.1, 14.4.0 and 14.4.1 > > > > > > We proposed reverts of [1] and those reverts are now in gate. As soon as they will be merged we will release new, fixed versions for both Stein and Train. > > > So if You didn't update to those broken versions yet, please don't do it now and wait for next version with fix. > > > > > > If You already updated and fixed that issue on Your clusters - You will have exactly same problem during next update again. I know it's very bad but unfortunately we don't have any other way to fix that issue. > > > > > > [1] https://urldefense.com/v3/__https://review.opendev.org/*/c/744133/__;Iw!!Ci6f514n9QsL8ck!15u_iIzQ-cPwno7OIj7ytuTQCHm8gkq6RnVO5dEhZqonxFOz-Brbri7Ly_T4RxwbZA$ > > > [2] https://urldefense.com/v3/__https://bugs.launchpad.net/neutron/*bug/1903531__;Kw!!Ci6f514n9QsL8ck!15u_iIzQ-cPwno7OIj7ytuTQCHm8gkq6RnVO5dEhZqonxFOz-Brbri7Ly_T6u2Bf9w$ > > > > > > -- > > > Slawek Kaplonski > > > Principal Software Engineer > > > Red Hat > > > > > > > > > > > > > -- > > Slawek Kaplonski > > Principal Software Engineer > > Red Hat > > > > > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat -- Slawek Kaplonski Principal Software Engineer Red Hat From arxcruz at redhat.com Wed Nov 25 09:30:21 2020 From: arxcruz at redhat.com (Arx Cruz) Date: Wed, 25 Nov 2020 10:30:21 +0100 Subject: [tripleo] Please avoid merge patches for releases before Victoria Message-ID: Hello, We need these patches [1] landed first in order to merge other patches, otherwise CI will not be able to properly test it. We have already had two known issues [2] related to this problem, so I ask you for patience while we are merging those patches. [1] https://review.opendev.org/c/openstack/tripleo-quickstart/+/763747 https://review.opendev.org/#/c/763712 [2] https://launchpad.net/bugs/1903033 https://bugs.launchpad.net/tripleo/+bug/1905536 Kind regards, -- Arx Cruz Software Engineer Red Hat EMEA arxcruz at redhat.com @RedHat Red Hat Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Wed Nov 25 09:32:41 2020 From: hberaud at redhat.com (Herve Beraud) Date: Wed, 25 Nov 2020 10:32:41 +0100 Subject: [release][infra[PTL] SSH key error - RedFlag stop approving In-Reply-To: References: Message-ID: Hello, After a series of tests this morning and yesterday evening, we can consider our previous issue is now solved, and we can restart approving the releases as usual. Indeed, all patches needed to fix our problem are now merged. Also the following refs who failed previously have been successfully reenqueued and stein-em tags are now available for the corresponding projects' repos: - 2f6e3e30f67df4f60e0e2b386755118bb1338059 [1] - f2b5d964aa5fd3290ca82c0cd12baa29e679b687 [2] - 3f2136e225577bf80cc90481db8e8aced937e5ec [3] - 7bf3e98f71afeeafdd703390390677728f1749e6 [4] - ec68594ba6faeb92eb9ad82410e3ab91db023b19 [5] To ensure that everything works as expected we also tested the following refs, tags and deliverables have been successfully created, and no error happened during jobs executions: - 1ddbb150446de8ab12676b6c896eadb8ed12d7c3 [6] - cb115f82fd52605690bdf9bc7c44c0f7d65ff1a4 [7] We can close this topic and return to normal activity. Thanks all for your patience. [1] https://opendev.org/openstack/releases/commit/2f6e3e30f67df4f60e0e2b386755118bb1338059 [2] https://opendev.org/openstack/releases/commit/f2b5d964aa5fd3290ca82c0cd12baa29e679b687 [3] https://opendev.org/openstack/releases/commit/3f2136e225577bf80cc90481db8e8aced937e5ec [4] https://opendev.org/openstack/releases/commit/7bf3e98f71afeeafdd703390390677728f1749e6 [5] https://opendev.org/openstack/releases/commit/ec68594ba6faeb92eb9ad82410e3ab91db023b19 [6] https://opendev.org/openstack/releases/commit/1ddbb150446de8ab12676b6c896eadb8ed12d7c3 [7] https://opendev.org/openstack/releases/commit/cb115f82fd52605690bdf9bc7c44c0f7d65ff1a4 Le mar. 24 nov. 2020 à 18:37, Herve Beraud a écrit : > Just a quick reminder of the current state of the openstack release > management. > > We are stuck by the SSH issue and we stopped approving release by waiting > to fix all elements of the problem. > > Three patches are on the rails to solve the issue, however one isn't yet > merged: > - https://review.opendev.org/c/openstack/project-config/+/763797/ (merged) > - https://review.opendev.org/c/openstack/project-config/+/763830/ (merged) > - https://review.opendev.org/c/zuul/zuul-jobs/+/763834/ (not merged) > > We are stopping approving releases until this issue isn't resolved. > > When all these patches will be merged we will try to re-enqueue our > failing ref to observe if it solves our issue and we will decide if we can > restart approving releases. > > I added the PTLs to the object of this thread to inform them about that and > also so that they are not surprised that we do not approve their release > patches. > > We will communicate as soon as we will restart approving release patches. > > Thanks for your comprehension. > > Le lun. 23 nov. 2020 à 12:49, Herve Beraud a écrit : > >> Hello, >> >> We are facing SSH issues on our release jobs [1][2]. >> Indeed, our release account failed to connect to gerrit through SSH [2]. >> The ID seems to be recognized when we try it. >> So that would probably mean we have a stale host key on the machine the script is running on . >> >> We suppose that the issue could be a side effect of the gerrit upgrade, we updated the etherpad to inform the infra team [3] >> >> @release managers: We should stop approving, so, please hold all our unmerged patches while this incident isn't solved. >> >> Thanks for your reading, >> >> [1] >> http://lists.openstack.org/pipermail/release-job-failures/2020-November/001487.html[2] >> Example of faced error: >> ``` >> ssh://release at review.opendev.org:29418/openstack/python-senlinclient.git >> did not work. Description: Host key verification failed. >> Could not read from remote repository >> ``` >> [3] https://etherpad.opendev.org/p/gerrit-3.2-post-upgrade-notes >> >> -- >> Hervé Beraud >> Senior Software Engineer at Red Hat >> irc: hberaud >> https://github.com/4383/ >> https://twitter.com/4383hberaud >> -----BEGIN PGP SIGNATURE----- >> >> wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ >> Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ >> RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP >> F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G >> 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g >> glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw >> m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ >> hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 >> qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y >> F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 >> B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O >> v6rDpkeNksZ9fFSyoY2o >> =ECSj >> -----END PGP SIGNATURE----- >> >> > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at est.tech Wed Nov 25 10:13:23 2020 From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer) Date: Wed, 25 Nov 2020 11:13:23 +0100 Subject: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] =?UTF-8?Q?Nova=0D=0A?= enforces that no DB credentials are allowed for the nova-compute service In-Reply-To: References: <6feed46a-c1b8-74ac-f59a-d45b2bfefd67@debian.org> Message-ID: On Mon, Nov 23, 2020 at 13:47, Thomas Goirand wrote: > On 11/23/20 11:31 AM, Balázs Gibizer wrote: >> It is still a security problem if nova-compute ignores the config >> as the >> config still exists on the hypervisor node (in some deployment >> scenarios) > > Let's say we apply the patch you're proposing, and that nova-compute > isn't loaded anymore with the db credentials, because it's on a > separate > file, and nova-compute doesn't load it. > > In such scenario, the /etc/nova/nova-db.conf could still be present > with > db credentials filled-in. So, the patch you're proposing is still not > effective for wrong configuration of nova-compute hosts. Obviously we cannot prevent that the deployer stores the DB creds on a compute host as we cannot detect it in general. But we can detect it if it is stored in the config the nova-compute reads. I don't know why should we not make sure to tell the deployer not to do that as it is generally considered unsafe. > >> From the nova-compute perspective we might be able to >> replace the [api_database]connection dependency with some hack. E.g >> to >> put the service name to the global CONF object at the start of the >> service binary and depend on that instead of other part of the >> config. >> But I feel pretty bad about this hack. > > Because of the above, I very much think it'd be the best way to go, > but > I understand your point of view. Going to the /etc/nova/nova-db.conf > and > nova-api-db.conf thing is probably good anyways. > > As for the nova-conductor thing, I very much would prefer if we had a > clean and explicit "superconductor=true" directive, with possibly some > checks to display big warnings in the nova-conductor.log file in case > of > a wrong configuration. If we don't have that, then at least things > must > be extensively documented, because that's really not obvious what's > going on. I agree that superconductor=true would be a more explicit config option than [api_database]connection. However this would also enforce that deployers need a separate config file for nova-compute as there neither superconductor=true nor superconductor=false (meaning it is a cell conductor) make sense. > > Cheers, > > Thomas Goirand (zigo) > From dtantsur at redhat.com Wed Nov 25 10:54:13 2020 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Wed, 25 Nov 2020 11:54:13 +0100 Subject: [ironic] [infra] Making Glean work with IPA for static IP assignment In-Reply-To: <20201125020901.GA522326@fedora19.localdomain> References: <20201125020901.GA522326@fedora19.localdomain> Message-ID: Hi, Thank you for your input! On Wed, Nov 25, 2020 at 3:09 AM Ian Wienand wrote: > On Tue, Nov 24, 2020 at 11:54:55AM +0100, Dmitry Tantsur wrote: > > The problem is, I cannot make Glean work with any ramdisk I build. The > crux > > of the problem seems to be that NetworkManager (used by default in RHEL, > > CentOS, Fedora and Debian at least) starts very early, creates the > default > > connection and ignores whatever files Glean happens to write afterwards. > On > > Debian running `systemctl restart networking` actually helped to pick the > > new configuration, but I'm not sure we want to do that in Glean. I > haven't > > been able to make NetworkManager pick up the changes on RH systems so > far. > > So we do use NetworkManager in the OpenDev images, and we do not see > NetworkManager starting before glean. > Okay, thanks for confirming. Maybe it's related to how IPA is built? It's not exactly a normal image after all, although it's pretty close to one. > > The way it should work is that simple-init in dib installs glean to > the image. That runs the glean install script (use --use-nm argument > if DIB_SIMPLE_INIT_NETWORKMANAGER, which is default on centos/fedora) > which installs two things; udev rules and a systemd handler. > I have checked that these are installed, but I don't know how to verify a udev rule. > > The udev is pretty simple [1] and should add a "Wants" for each net > device; e.g. eth1 would match and create a Wants glean at eth1.service, > which then matches [2] which should write out the ifcfg config file. > After this, NetworkManager should start, notice the config file for > the interface and bring it up. > Yeah, I definitely see logging from NetworkManager DHCP before this service is run (i.e. before the output from Glean). > > > Do you maybe have any hints how to proceed? I'd be curious to know how > > static IP assignment works in the infra setup. Do you have images with > > NetworkManager there? Do you use the simple-init element? > > As noted yes we use this. Really only in two contexts; it's Rackspace > that doesn't have DHCP so we have to setup the interface statically > from the configdrive data. Other clouds all provide DHCP, which is > used when there's no configdrive data. > > Here is a systemd-analyze from one of our Centos nodes if it helps: > > graphical.target @18.403s > └─multi-user.target @18.403s > └─unbound.service @5.467s +12.934s > └─network.target @5.454s > └─NetworkManager.service @5.339s +112ms > └─network-pre.target @5.334s > └─glean at ens3.service @4.227s +1.102s > └─basic.target @4.167s > └─sockets.target @4.166s > └─iscsiuio.socket @4.165s > └─sysinit.target @4.153s > └─systemd-udev-settle.service @1.905s +2.245s > └─systemd-udev-trigger.service @1.242s +659ms > └─systemd-udevd-control.socket @1.239s > └─system.slice > # systemd-analyze critical-chain multi-user.target @2min 6.301s └─tuned.service @1min 32.273s +34.024s └─network.target @1min 31.590s └─network-pre.target @1min 31.579s └─glean at enp1s0.service @36.594s +54.952s └─system-glean.slice @36.493s └─system.slice @4.083s └─-.slice @4.080s # systemd-analyze critical-chain NetworkManager.service NetworkManager.service +9.287s └─network-pre.target @1min 31.579s └─glean at enp1s0.service @36.594s +54.952s └─system-glean.slice @36.493s └─system.slice @4.083s └─-.slice @4.080s # cat /etc/sysconfig/network-scripts/ifcfg-enp1s0 # Automatically generated, do not edit DEVICE=enp1s0 BOOTPROTO=static HWADDR=52:54:00:1f:79:7e IPADDR=192.168.122.42 NETMASK=255.255.255.0 ONBOOT=yes NM_CONTROLLED=yes # ip addr ... 2: enp1s0: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:1f:79:7e brd ff:ff:ff:ff:ff:ff inet 192.168.122.77/24 brd 192.168.122.255 scope global dynamic noprefixroute enp1s0 valid_lft 42957sec preferred_lft 42957sec inet6 fe80::f182:7fb4:7a39:eb7b/64 scope link noprefixroute valid_lft forever preferred_lft forever > At a guess; I feel like the udev bits are probably not happening > correctly in your case? That's important to get the glean@ > service in the chain to pre-create the config file > It seems that the ordering is correct and the interface service is executed, but the IP address is nonetheless wrong. Can it be related to how long glean takes to run in my case (54 seconds vs 1 second in your case)? Dmitry > > -i > > [1] > https://opendev.org/opendev/glean/src/branch/master/glean/init/glean-udev.rules > [2] > https://opendev.org/opendev/glean/src/branch/master/glean/init/glean-nm at .service > > -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbasaras at gmail.com Wed Nov 25 12:52:56 2020 From: pbasaras at gmail.com (Pavlos Basaras) Date: Wed, 25 Nov 2020 14:52:56 +0200 Subject: [neutron] [nova] [ussuri] IP of the VM at the provider network is different than the one registered at the Openstack controller Message-ID: Hello, Setup: i follow the main instruction for deploying openstack for learning purposes. I can successfully deploy vms in an internal network, and also connect them to a router that gives internet access using floating ips etc. My setup is based on ubuntu 18. I have virtualbox for deploying controller (10.0.0.11) and compute (10.0.0.31) etc. I have host only adapters at virtual box (dhcp enabled) for the two networks: mgmt: 10.0.0.0/24 and provider 203.0.111.0/24 as per the default instructions, and i use iptables to NAT the vms. Problem: When following the instructions from https://docs.openstack.org/install-guide/launch-instance-provider.html the vm is deployed successfully but the ip that it is assigned is different from the one that the controller has. It seems that there are more than one dhcp instances running? How can i debug this? Any advice? all the best, Pavlos. -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliver.wenz at dhbw-mannheim.de Wed Nov 25 13:01:45 2020 From: oliver.wenz at dhbw-mannheim.de (Oliver Wenz) Date: Wed, 25 Nov 2020 14:01:45 +0100 Subject: [neutron][openstack-ansible] Instances can only connect to provider-net via tenant-net but not directly In-Reply-To: References: Message-ID: <6fa8f3b8-0145-aabc-e389-63a1ea5ec8db@dhbw-mannheim.de> Hi, Starting instances which are connected directly to a provider network results in an error in my Ussuri cloud. However, I can associate floating IPs for this provider network when I connect instances to it via a tenant network and it works fine. Both nova-compute and neutron-linuxbridge-agent services don't show errors, I only get an error in the instance status: 'code': 500, 'created': '2020-11-25T12:05:42Z', 'message': 'Build of instance 274e0a7d-fb33-430a-986e-74fceae6a36d aborted: Failed to allocate the network(s), not rescheduling.', 'details': 'Traceback (most recent call last): File "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/virt/libvirt/driver.py", line 6549, in _create_domain_and_network post_xml_callback=post_xml_callback) File "/usr/lib/python3.6/contextlib.py", line 88, in __exit__ next(self.gen) File "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/compute/manager.py", line 513, in wait_for_instance_event actual_event = event.wait() File "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/eventlet/event.py", line 125, in wait result = hub.switch() File "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/eventlet/hubs/hub.py", line 298, in switch return self.greenlet.switch() eventlet.timeout.Timeout: 300 seconds During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/compute/manager.py", line 2378, in _build_and_run_instance accel_info=accel_info) File "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/virt/libvirt/driver.py", line 3683, in spawn cleanup_instance_disks=created_disks) File "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/virt/libvirt/driver.py", line 6572, in _create_domain_and_network raise exception.VirtualInterfaceCreateException() nova.exception.VirtualInterfaceCreateException: Virtual Interface creation failed During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/compute/manager.py", line 2200, in _do_build_and_run_instance filter_properties, request_spec, accel_uuids) File "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/compute/manager.py", line 2444, in _build_and_run_instance reason=msg) nova.exception.BuildAbortException: Build of instance 274e0a7d-fb33-430a-986e-74fceae6a36d aborted: Failed to allocate the network(s), not rescheduling. ' Any ideas what could cause this? Kind regards, Oliver On 2020-11-25 13:00, openstack-discuss-request at lists.openstack.org wrote: > Send openstack-discuss mailing list submissions to > openstack-discuss at lists.openstack.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss > or, via email, send a message with subject or body 'help' to > openstack-discuss-request at lists.openstack.org > > You can reach the person managing the list at > openstack-discuss-owner at lists.openstack.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openstack-discuss digest..." > > > Today's Topics: > > 1. Re: > [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova > enforces that no DB credentials are allowed for the nova-compute > service (Balázs Gibizer) > 2. Re: [ironic] [infra] Making Glean work with IPA for static IP > assignment (Dmitry Tantsur) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 25 Nov 2020 11:13:23 +0100 > From: Balázs Gibizer > To: Thomas Goirand > Cc: openstack maillist > Subject: Re: > [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova > enforces that no DB credentials are allowed for the nova-compute > service > Message-ID: > Content-Type: text/plain; charset=iso-8859-1; format=flowed > > > > On Mon, Nov 23, 2020 at 13:47, Thomas Goirand wrote: >> On 11/23/20 11:31 AM, Balázs Gibizer wrote: >>> It is still a security problem if nova-compute ignores the config >>> as the >>> config still exists on the hypervisor node (in some deployment >>> scenarios) >> >> Let's say we apply the patch you're proposing, and that nova-compute >> isn't loaded anymore with the db credentials, because it's on a >> separate >> file, and nova-compute doesn't load it. >> >> In such scenario, the /etc/nova/nova-db.conf could still be present >> with >> db credentials filled-in. So, the patch you're proposing is still not >> effective for wrong configuration of nova-compute hosts. > > Obviously we cannot prevent that the deployer stores the DB creds on a > compute host as we cannot detect it in general. But we can detect it if > it is stored in the config the nova-compute reads. I don't know why > should we not make sure to tell the deployer not to do that as it is > generally considered unsafe. > >> >>> From the nova-compute perspective we might be able to >>> replace the [api_database]connection dependency with some hack. E.g >>> to >>> put the service name to the global CONF object at the start of the >>> service binary and depend on that instead of other part of the >>> config. >>> But I feel pretty bad about this hack. >> >> Because of the above, I very much think it'd be the best way to go, >> but >> I understand your point of view. Going to the /etc/nova/nova-db.conf >> and >> nova-api-db.conf thing is probably good anyways. >> >> As for the nova-conductor thing, I very much would prefer if we had a >> clean and explicit "superconductor=true" directive, with possibly some >> checks to display big warnings in the nova-conductor.log file in case >> of >> a wrong configuration. If we don't have that, then at least things >> must >> be extensively documented, because that's really not obvious what's >> going on. > > I agree that superconductor=true would be a more explicit config option > than [api_database]connection. However this would also enforce that > deployers need a separate config file for nova-compute as there neither > superconductor=true nor superconductor=false (meaning it is a cell > conductor) make sense. > >> >> Cheers, >> >> Thomas Goirand (zigo) >> > > > > > > ------------------------------ > > Message: 2 > Date: Wed, 25 Nov 2020 11:54:13 +0100 > From: Dmitry Tantsur > To: Ian Wienand > Cc: openstack-discuss > Subject: Re: [ironic] [infra] Making Glean work with IPA for static IP > assignment > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Hi, > > Thank you for your input! > > On Wed, Nov 25, 2020 at 3:09 AM Ian Wienand wrote: > >> On Tue, Nov 24, 2020 at 11:54:55AM +0100, Dmitry Tantsur wrote: >>> The problem is, I cannot make Glean work with any ramdisk I build. The >> crux >>> of the problem seems to be that NetworkManager (used by default in RHEL, >>> CentOS, Fedora and Debian at least) starts very early, creates the >> default >>> connection and ignores whatever files Glean happens to write afterwards. >> On >>> Debian running `systemctl restart networking` actually helped to pick the >>> new configuration, but I'm not sure we want to do that in Glean. I >> haven't >>> been able to make NetworkManager pick up the changes on RH systems so >> far. >> >> So we do use NetworkManager in the OpenDev images, and we do not see >> NetworkManager starting before glean. >> > > Okay, thanks for confirming. Maybe it's related to how IPA is built? It's > not exactly a normal image after all, although it's pretty close to one. > > >> >> The way it should work is that simple-init in dib installs glean to >> the image. That runs the glean install script (use --use-nm argument >> if DIB_SIMPLE_INIT_NETWORKMANAGER, which is default on centos/fedora) >> which installs two things; udev rules and a systemd handler. >> > > I have checked that these are installed, but I don't know how to verify a > udev rule. > > >> >> The udev is pretty simple [1] and should add a "Wants" for each net >> device; e.g. eth1 would match and create a Wants glean at eth1.service, >> which then matches [2] which should write out the ifcfg config file. >> After this, NetworkManager should start, notice the config file for >> the interface and bring it up. >> > > Yeah, I definitely see logging from NetworkManager DHCP before this service > is run (i.e. before the output from Glean). > > >> >>> Do you maybe have any hints how to proceed? I'd be curious to know how >>> static IP assignment works in the infra setup. Do you have images with >>> NetworkManager there? Do you use the simple-init element? >> >> As noted yes we use this. Really only in two contexts; it's Rackspace >> that doesn't have DHCP so we have to setup the interface statically >> from the configdrive data. Other clouds all provide DHCP, which is >> used when there's no configdrive data. >> >> Here is a systemd-analyze from one of our Centos nodes if it helps: >> > >> graphical.target @18.403s >> └─multi-user.target @18.403s >> └─unbound.service @5.467s +12.934s >> └─network.target @5.454s >> └─NetworkManager.service @5.339s +112ms >> └─network-pre.target @5.334s >> └─glean at ens3.service @4.227s +1.102s >> └─basic.target @4.167s >> └─sockets.target @4.166s >> └─iscsiuio.socket @4.165s >> └─sysinit.target @4.153s >> └─systemd-udev-settle.service @1.905s +2.245s >> └─systemd-udev-trigger.service @1.242s +659ms >> └─systemd-udevd-control.socket @1.239s >> └─system.slice >> > > # systemd-analyze critical-chain > multi-user.target @2min 6.301s > └─tuned.service @1min 32.273s +34.024s > └─network.target @1min 31.590s > └─network-pre.target @1min 31.579s > └─glean at enp1s0.service @36.594s +54.952s > └─system-glean.slice @36.493s > └─system.slice @4.083s > └─-.slice @4.080s > > # systemd-analyze critical-chain NetworkManager.service > NetworkManager.service +9.287s > └─network-pre.target @1min 31.579s > └─glean at enp1s0.service @36.594s +54.952s > └─system-glean.slice @36.493s > └─system.slice @4.083s > └─-.slice @4.080s > > # cat /etc/sysconfig/network-scripts/ifcfg-enp1s0 > # Automatically generated, do not edit > DEVICE=enp1s0 > BOOTPROTO=static > HWADDR=52:54:00:1f:79:7e > IPADDR=192.168.122.42 > NETMASK=255.255.255.0 > ONBOOT=yes > NM_CONTROLLED=yes > > # ip addr > ... > 2: enp1s0: mtu 1500 qdisc fq_codel state > UP group default qlen 1000 > link/ether 52:54:00:1f:79:7e brd ff:ff:ff:ff:ff:ff > inet 192.168.122.77/24 brd 192.168.122.255 scope global dynamic > noprefixroute enp1s0 > valid_lft 42957sec preferred_lft 42957sec > inet6 fe80::f182:7fb4:7a39:eb7b/64 scope link noprefixroute > valid_lft forever preferred_lft forever > > >> At a guess; I feel like the udev bits are probably not happening >> correctly in your case? That's important to get the glean@ >> service in the chain to pre-create the config file >> > > It seems that the ordering is correct and the interface service is > executed, but the IP address is nonetheless wrong. > > Can it be related to how long glean takes to run in my case (54 seconds vs > 1 second in your case)? > > Dmitry > > >> >> -i >> >> [1] >> https://opendev.org/opendev/glean/src/branch/master/glean/init/glean-udev.rules >> [2] >> https://opendev.org/opendev/glean/src/branch/master/glean/init/glean-nm at .service >> >> > From noonedeadpunk at ya.ru Wed Nov 25 13:31:12 2020 From: noonedeadpunk at ya.ru (Dmitriy Rabotyagov) Date: Wed, 25 Nov 2020 15:31:12 +0200 Subject: [neutron][openstack-ansible] Instances can only connect to provider-net via tenant-net but not directly In-Reply-To: <6fa8f3b8-0145-aabc-e389-63a1ea5ec8db@dhbw-mannheim.de> References: <6fa8f3b8-0145-aabc-e389-63a1ea5ec8db@dhbw-mannheim.de> Message-ID: <1114661606310693@mail.yandex.ru> Hi Oliver. I think there might be pretty much reasons of this behavior and at the moment I don't have enough info to say what exactly this might be. First of all I'd suggest checking `openstack network agent list` and ensure that lxb agent is present there up and healthy. Next I'd check nova-scheduler log (journalctl eventually) as it might have more insights. Floating IP traffic for tenant networks goes through network nodes, where neutron-l3-agent is placed, while direct connection requires that interface for flat (provider) network would be present on the compute host and be able to be added to the bridge by lxb. 25.11.2020, 15:08, "Oliver Wenz" : > Hi, > Starting instances which are connected directly to a provider network > results in an error in my Ussuri cloud. However, I can associate > floating IPs for this provider network when I connect instances to it > via a tenant network and it works fine. > Both nova-compute and neutron-linuxbridge-agent services don't show > errors, I only get an error in the instance status: > > 'code': 500, 'created': '2020-11-25T12:05:42Z', 'message': 'Build of > instance 274e0a7d-fb33-430a-986e-74fceae6a36d aborted: Failed to > allocate the network(s), not rescheduling.', 'details': 'Traceback (most > recent call last): >   File > "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/virt/libvirt/driver.py", > line 6549, in _create_domain_and_network >     post_xml_callback=post_xml_callback) >   File "/usr/lib/python3.6/contextlib.py", line 88, in __exit__ >     next(self.gen) >   File > "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/compute/manager.py", > line 513, in wait_for_instance_event >     actual_event = event.wait() >   File > "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/eventlet/event.py", > line 125, in wait >     result = hub.switch() >   File > "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/eventlet/hubs/hub.py", > line 298, in switch >     return self.greenlet.switch() > eventlet.timeout.Timeout: 300 seconds > > During handling of the above exception, another exception occurred: > > Traceback (most recent call last): >   File > "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/compute/manager.py", > line 2378, in _build_and_run_instance >     accel_info=accel_info) >   File > "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/virt/libvirt/driver.py", > line 3683, in spawn >     cleanup_instance_disks=created_disks) >   File > "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/virt/libvirt/driver.py", > line 6572, in _create_domain_and_network >     raise exception.VirtualInterfaceCreateException() > nova.exception.VirtualInterfaceCreateException: Virtual Interface > creation failed > > During handling of the above exception, another exception occurred: > > Traceback (most recent call last): >   File > "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/compute/manager.py", > line 2200, in _do_build_and_run_instance >     filter_properties, request_spec, accel_uuids) >   File > "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/compute/manager.py", > line 2444, in _build_and_run_instance >     reason=msg) > nova.exception.BuildAbortException: Build of instance > 274e0a7d-fb33-430a-986e-74fceae6a36d aborted: Failed to allocate the > network(s), not rescheduling. > ' > > Any ideas what could cause this? > > Kind regards, > Oliver > > On 2020-11-25 13:00, openstack-discuss-request at lists.openstack.org wrote: >>  Send openstack-discuss mailing list submissions to >>          openstack-discuss at lists.openstack.org >> >>  To subscribe or unsubscribe via the World Wide Web, visit >>          http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss >>  or, via email, send a message with subject or body 'help' to >>          openstack-discuss-request at lists.openstack.org >> >>  You can reach the person managing the list at >>          openstack-discuss-owner at lists.openstack.org >> >>  When replying, please edit your Subject line so it is more specific >>  than "Re: Contents of openstack-discuss digest..." >> >>  Today's Topics: >> >>     1. Re: >>        [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova >>        enforces that no DB credentials are allowed for the nova-compute >>        service (Balázs Gibizer) >>     2. Re: [ironic] [infra] Making Glean work with IPA for static IP >>        assignment (Dmitry Tantsur) >> >>  ---------------------------------------------------------------------- >> >>  Message: 1 >>  Date: Wed, 25 Nov 2020 11:13:23 +0100 >>  From: Balázs Gibizer >>  To: Thomas Goirand >>  Cc: openstack maillist >>  Subject: Re: >>          [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova >>          enforces that no DB credentials are allowed for the nova-compute >>          service >>  Message-ID: >>  Content-Type: text/plain; charset=iso-8859-1; format=flowed >> >>  On Mon, Nov 23, 2020 at 13:47, Thomas Goirand wrote: >>>  On 11/23/20 11:31 AM, Balázs Gibizer wrote: >>>>   It is still a security problem if nova-compute ignores the config >>>>  as the >>>>   config still exists on the hypervisor node (in some deployment >>>>  scenarios) >>> >>>  Let's say we apply the patch you're proposing, and that nova-compute >>>  isn't loaded anymore with the db credentials, because it's on a >>>  separate >>>  file, and nova-compute doesn't load it. >>> >>>  In such scenario, the /etc/nova/nova-db.conf could still be present >>>  with >>>  db credentials filled-in. So, the patch you're proposing is still not >>>  effective for wrong configuration of nova-compute hosts. >> >>  Obviously we cannot prevent that the deployer stores the DB creds on a >>  compute host as we cannot detect it in general. But we can detect it if >>  it is stored in the config the nova-compute reads. I don't know why >>  should we not make sure to tell the deployer not to do that as it is >>  generally considered unsafe. >> >>>>   From the nova-compute perspective we might be able to >>>>   replace the [api_database]connection dependency with some hack. E.g >>>>  to >>>>   put the service name to the global CONF object at the start of the >>>>   service binary and depend on that instead of other part of the >>>>  config. >>>>   But I feel pretty bad about this hack. >>> >>>  Because of the above, I very much think it'd be the best way to go, >>>  but >>>  I understand your point of view. Going to the /etc/nova/nova-db.conf >>>  and >>>  nova-api-db.conf thing is probably good anyways. >>> >>>  As for the nova-conductor thing, I very much would prefer if we had a >>>  clean and explicit "superconductor=true" directive, with possibly some >>>  checks to display big warnings in the nova-conductor.log file in case >>>  of >>>  a wrong configuration. If we don't have that, then at least things >>>  must >>>  be extensively documented, because that's really not obvious what's >>>  going on. >> >>  I agree that superconductor=true would be a more explicit config option >>  than [api_database]connection. However this would also enforce that >>  deployers need a separate config file for nova-compute as there neither >>  superconductor=true nor superconductor=false (meaning it is a cell >>  conductor) make sense. >> >>>  Cheers, >>> >>>  Thomas Goirand (zigo) >> >>  ------------------------------ >> >>  Message: 2 >>  Date: Wed, 25 Nov 2020 11:54:13 +0100 >>  From: Dmitry Tantsur >>  To: Ian Wienand >>  Cc: openstack-discuss >>  Subject: Re: [ironic] [infra] Making Glean work with IPA for static IP >>          assignment >>  Message-ID: >>           >>  Content-Type: text/plain; charset="utf-8" >> >>  Hi, >> >>  Thank you for your input! >> >>  On Wed, Nov 25, 2020 at 3:09 AM Ian Wienand wrote: >> >>>  On Tue, Nov 24, 2020 at 11:54:55AM +0100, Dmitry Tantsur wrote: >>>>  The problem is, I cannot make Glean work with any ramdisk I build. The >>>  crux >>>>  of the problem seems to be that NetworkManager (used by default in RHEL, >>>>  CentOS, Fedora and Debian at least) starts very early, creates the >>>  default >>>>  connection and ignores whatever files Glean happens to write afterwards. >>>  On >>>>  Debian running `systemctl restart networking` actually helped to pick the >>>>  new configuration, but I'm not sure we want to do that in Glean. I >>>  haven't >>>>  been able to make NetworkManager pick up the changes on RH systems so >>>  far. >>> >>>  So we do use NetworkManager in the OpenDev images, and we do not see >>>  NetworkManager starting before glean. >> >>  Okay, thanks for confirming. Maybe it's related to how IPA is built? It's >>  not exactly a normal image after all, although it's pretty close to one. >> >>>  The way it should work is that simple-init in dib installs glean to >>>  the image. That runs the glean install script (use --use-nm argument >>>  if DIB_SIMPLE_INIT_NETWORKMANAGER, which is default on centos/fedora) >>>  which installs two things; udev rules and a systemd handler. >> >>  I have checked that these are installed, but I don't know how to verify a >>  udev rule. >> >>>  The udev is pretty simple [1] and should add a "Wants" for each net >>>  device; e.g. eth1 would match and create a Wants glean at eth1.service, >>>  which then matches [2] which should write out the ifcfg config file. >>>  After this, NetworkManager should start, notice the config file for >>>  the interface and bring it up. >> >>  Yeah, I definitely see logging from NetworkManager DHCP before this service >>  is run (i.e. before the output from Glean). >> >>>>  Do you maybe have any hints how to proceed? I'd be curious to know how >>>>  static IP assignment works in the infra setup. Do you have images with >>>>  NetworkManager there? Do you use the simple-init element? >>> >>>  As noted yes we use this. Really only in two contexts; it's Rackspace >>>  that doesn't have DHCP so we have to setup the interface statically >>>  from the configdrive data. Other clouds all provide DHCP, which is >>>  used when there's no configdrive data. >>> >>>  Here is a systemd-analyze from one of our Centos nodes if it helps: >> >>>  graphical.target @18.403s >>>  └─multi-user.target @18.403s >>>    └─unbound.service @5.467s +12.934s >>>      └─network.target @5.454s >>>        └─NetworkManager.service @5.339s +112ms >>>          └─network-pre.target @5.334s >>>            └─glean at ens3.service @4.227s +1.102s >>>              └─basic.target @4.167s >>>                └─sockets.target @4.166s >>>                  └─iscsiuio.socket @4.165s >>>                    └─sysinit.target @4.153s >>>                      └─systemd-udev-settle.service @1.905s +2.245s >>>                        └─systemd-udev-trigger.service @1.242s +659ms >>>                          └─systemd-udevd-control.socket @1.239s >>>                            └─system.slice >> >>  # systemd-analyze critical-chain >>  multi-user.target @2min 6.301s >>  └─tuned.service @1min 32.273s +34.024s >>    └─network.target @1min 31.590s >>      └─network-pre.target @1min 31.579s >>        └─glean at enp1s0.service @36.594s +54.952s >>          └─system-glean.slice @36.493s >>            └─system.slice @4.083s >>              └─-.slice @4.080s >> >>  # systemd-analyze critical-chain NetworkManager.service >>  NetworkManager.service +9.287s >>  └─network-pre.target @1min 31.579s >>    └─glean at enp1s0.service @36.594s +54.952s >>      └─system-glean.slice @36.493s >>        └─system.slice @4.083s >>          └─-.slice @4.080s >> >>  # cat /etc/sysconfig/network-scripts/ifcfg-enp1s0 >>  # Automatically generated, do not edit >>  DEVICE=enp1s0 >>  BOOTPROTO=static >>  HWADDR=52:54:00:1f:79:7e >>  IPADDR=192.168.122.42 >>  NETMASK=255.255.255.0 >>  ONBOOT=yes >>  NM_CONTROLLED=yes >> >>  # ip addr >>  ... >>  2: enp1s0: mtu 1500 qdisc fq_codel state >>  UP group default qlen 1000 >>      link/ether 52:54:00:1f:79:7e brd ff:ff:ff:ff:ff:ff >>      inet 192.168.122.77/24 brd 192.168.122.255 scope global dynamic >>  noprefixroute enp1s0 >>         valid_lft 42957sec preferred_lft 42957sec >>      inet6 fe80::f182:7fb4:7a39:eb7b/64 scope link noprefixroute >>         valid_lft forever preferred_lft forever >> >>>  At a guess; I feel like the udev bits are probably not happening >>>  correctly in your case? That's important to get the glean@ >>>  service in the chain to pre-create the config file >> >>  It seems that the ordering is correct and the interface service is >>  executed, but the IP address is nonetheless wrong. >> >>  Can it be related to how long glean takes to run in my case (54 seconds vs >>  1 second in your case)? >> >>  Dmitry >> >>>  -i >>> >>>  [1] >>>  https://opendev.org/opendev/glean/src/branch/master/glean/init/glean-udev.rules >>>  [2] >>>  https://opendev.org/opendev/glean/src/branch/master/glean/init/glean-nm at .service --  Kind Regards, Dmitriy Rabotyagov From mnaser at vexxhost.com Wed Nov 25 14:06:12 2020 From: mnaser at vexxhost.com (Mohammed Naser) Date: Wed, 25 Nov 2020 09:06:12 -0500 Subject: [tc] weekly update & agenda Message-ID: 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. # Patches ## Open Reviews - Clarify the requirements for supports-api-interoperability https://review.opendev.org/c/openstack/governance/+/760562 - Add election schedule exceptions in charter https://review.opendev.org/c/openstack/governance/+/751941 - Add Resolution of TC stance on the OpenStackClient https://review.opendev.org/c/openstack/governance/+/759904 - Add assert:supports-standalone https://review.opendev.org/c/openstack/governance/+/722399 - Remove assert_supports-zero-downtime-upgrade tag https://review.opendev.org/c/openstack/governance/+/761975 - Add Magpie charm to OpenStack charms https://review.opendev.org/c/openstack/governance/+/762820 - Propose Kendall Nelson for vice chair https://review.opendev.org/c/openstack/governance/+/762014 - Clarify impact on releases for SIGs https://review.opendev.org/c/openstack/governance/+/752699 ## General Changes - Move Placement under Nova's governance https://review.opendev.org/c/openstack/governance/+/760917 ## Other Reminders - Our next [TC] Weekly meeting is scheduled for November 26. If you would like to add topics for discussion, please go to https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting and fill out your suggestions by Wednesday, November 26th, at 0000 UTC. Thanks for reading! Mohammed & Kendall -- Mohammed Naser VEXXHOST, Inc. From christian.rohmann at inovex.de Wed Nov 25 14:28:57 2020 From: christian.rohmann at inovex.de (Christian Rohmann) Date: Wed, 25 Nov 2020 15:28:57 +0100 Subject: [neutron][operators][all] Watch out for updates of stable/train and stable/stein releases in Neutron In-Reply-To: <20201124215831.bryboz64jypo75eq@p1.localdomain> References: <20201124215831.bryboz64jypo75eq@p1.localdomain> Message-ID: <436a366a-730f-e29b-68bd-36c450b4a8f1@inovex.de> On 2020-11-24 22:58, Slawek Kaplonski wrote: > So if > You are now updating Your Stein or Train Neutron to latest version and You will > do it as it should be done, so first neutron-server and then agents, Your > neutron-ovs-agents will not work properly with newer neutron-server. > Details are in reported bug [2] Even though the original change might be OVS related, the incompatibility / issue I reported (also) arises with neutron-linuxbridge-agent, which my bug report is about actually. There the creation / update of ipsets / iptables fails. What exactly happens in the case of an installation running OVS I cannot say. Regards Christian From skaplons at redhat.com Wed Nov 25 14:55:06 2020 From: skaplons at redhat.com (Slawek Kaplonski) Date: Wed, 25 Nov 2020 15:55:06 +0100 Subject: [neutron][openstack-ansible] Instances can only connect to provider-net via tenant-net but not directly In-Reply-To: <6fa8f3b8-0145-aabc-e389-63a1ea5ec8db@dhbw-mannheim.de> References: <6fa8f3b8-0145-aabc-e389-63a1ea5ec8db@dhbw-mannheim.de> Message-ID: <20201125145506.rfzogzcm2dcntoal@p1.localdomain> Hi, On Wed, Nov 25, 2020 at 02:01:45PM +0100, Oliver Wenz wrote: > Hi, > Starting instances which are connected directly to a provider network > results in an error in my Ussuri cloud. However, I can associate > floating IPs for this provider network when I connect instances to it > via a tenant network and it works fine. > Both nova-compute and neutron-linuxbridge-agent services don't show > errors, I only get an error in the instance status: > > 'code': 500, 'created': '2020-11-25T12:05:42Z', 'message': 'Build of > instance 274e0a7d-fb33-430a-986e-74fceae6a36d aborted: Failed to > allocate the network(s), not rescheduling.', 'details': 'Traceback (most > recent call last): > File > "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/virt/libvirt/driver.py", > line 6549, in _create_domain_and_network > post_xml_callback=post_xml_callback) > File "/usr/lib/python3.6/contextlib.py", line 88, in __exit__ > next(self.gen) > File > "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/compute/manager.py", > line 513, in wait_for_instance_event > actual_event = event.wait() > File > "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/eventlet/event.py", > line 125, in wait > result = hub.switch() > File > "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/eventlet/hubs/hub.py", > line 298, in switch > return self.greenlet.switch() > eventlet.timeout.Timeout: 300 seconds > > During handling of the above exception, another exception occurred: > > Traceback (most recent call last): > File > "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/compute/manager.py", > line 2378, in _build_and_run_instance > accel_info=accel_info) > File > "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/virt/libvirt/driver.py", > line 3683, in spawn > cleanup_instance_disks=created_disks) > File > "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/virt/libvirt/driver.py", > line 6572, in _create_domain_and_network > raise exception.VirtualInterfaceCreateException() > nova.exception.VirtualInterfaceCreateException: Virtual Interface > creation failed > > During handling of the above exception, another exception occurred: > > Traceback (most recent call last): > File > "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/compute/manager.py", > line 2200, in _do_build_and_run_instance > filter_properties, request_spec, accel_uuids) > File > "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/compute/manager.py", > line 2444, in _build_and_run_instance > reason=msg) > nova.exception.BuildAbortException: Build of instance > 274e0a7d-fb33-430a-986e-74fceae6a36d aborted: Failed to allocate the > network(s), not rescheduling. > ' > > Any ideas what could cause this? Such errors usually means that there is some problem on Neutron side. Please check in neutron server logs for the problems with binding port for that vm or, if binding is done fine, check if both DHCP agent and L2 agents are reporitng that port is UP and provisioning block for that entity can be removed. Of course if You don't have dhcp enabled for that network/subnet, then You will not need to wait for provisioning by DHCP to be finished. If all is done correctly You should see in neutron logs that neutron is sending notification to nova that port is provisioned. > > Kind regards, > Oliver > > > On 2020-11-25 13:00, openstack-discuss-request at lists.openstack.org wrote: > > Send openstack-discuss mailing list submissions to > > openstack-discuss at lists.openstack.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss > > or, via email, send a message with subject or body 'help' to > > openstack-discuss-request at lists.openstack.org > > > > You can reach the person managing the list at > > openstack-discuss-owner at lists.openstack.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of openstack-discuss digest..." > > > > > > Today's Topics: > > > > 1. Re: > > [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova > > enforces that no DB credentials are allowed for the nova-compute > > service (Balázs Gibizer) > > 2. Re: [ironic] [infra] Making Glean work with IPA for static IP > > assignment (Dmitry Tantsur) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Wed, 25 Nov 2020 11:13:23 +0100 > > From: Balázs Gibizer > > To: Thomas Goirand > > Cc: openstack maillist > > Subject: Re: > > [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova > > enforces that no DB credentials are allowed for the nova-compute > > service > > Message-ID: > > Content-Type: text/plain; charset=iso-8859-1; format=flowed > > > > > > > > On Mon, Nov 23, 2020 at 13:47, Thomas Goirand wrote: > >> On 11/23/20 11:31 AM, Balázs Gibizer wrote: > >>> It is still a security problem if nova-compute ignores the config > >>> as the > >>> config still exists on the hypervisor node (in some deployment > >>> scenarios) > >> > >> Let's say we apply the patch you're proposing, and that nova-compute > >> isn't loaded anymore with the db credentials, because it's on a > >> separate > >> file, and nova-compute doesn't load it. > >> > >> In such scenario, the /etc/nova/nova-db.conf could still be present > >> with > >> db credentials filled-in. So, the patch you're proposing is still not > >> effective for wrong configuration of nova-compute hosts. > > > > Obviously we cannot prevent that the deployer stores the DB creds on a > > compute host as we cannot detect it in general. But we can detect it if > > it is stored in the config the nova-compute reads. I don't know why > > should we not make sure to tell the deployer not to do that as it is > > generally considered unsafe. > > > >> > >>> From the nova-compute perspective we might be able to > >>> replace the [api_database]connection dependency with some hack. E.g > >>> to > >>> put the service name to the global CONF object at the start of the > >>> service binary and depend on that instead of other part of the > >>> config. > >>> But I feel pretty bad about this hack. > >> > >> Because of the above, I very much think it'd be the best way to go, > >> but > >> I understand your point of view. Going to the /etc/nova/nova-db.conf > >> and > >> nova-api-db.conf thing is probably good anyways. > >> > >> As for the nova-conductor thing, I very much would prefer if we had a > >> clean and explicit "superconductor=true" directive, with possibly some > >> checks to display big warnings in the nova-conductor.log file in case > >> of > >> a wrong configuration. If we don't have that, then at least things > >> must > >> be extensively documented, because that's really not obvious what's > >> going on. > > > > I agree that superconductor=true would be a more explicit config option > > than [api_database]connection. However this would also enforce that > > deployers need a separate config file for nova-compute as there neither > > superconductor=true nor superconductor=false (meaning it is a cell > > conductor) make sense. > > > >> > >> Cheers, > >> > >> Thomas Goirand (zigo) > >> > > > > > > > > > > > > ------------------------------ > > > > Message: 2 > > Date: Wed, 25 Nov 2020 11:54:13 +0100 > > From: Dmitry Tantsur > > To: Ian Wienand > > Cc: openstack-discuss > > Subject: Re: [ironic] [infra] Making Glean work with IPA for static IP > > assignment > > Message-ID: > > > > Content-Type: text/plain; charset="utf-8" > > > > Hi, > > > > Thank you for your input! > > > > On Wed, Nov 25, 2020 at 3:09 AM Ian Wienand wrote: > > > >> On Tue, Nov 24, 2020 at 11:54:55AM +0100, Dmitry Tantsur wrote: > >>> The problem is, I cannot make Glean work with any ramdisk I build. The > >> crux > >>> of the problem seems to be that NetworkManager (used by default in RHEL, > >>> CentOS, Fedora and Debian at least) starts very early, creates the > >> default > >>> connection and ignores whatever files Glean happens to write afterwards. > >> On > >>> Debian running `systemctl restart networking` actually helped to pick the > >>> new configuration, but I'm not sure we want to do that in Glean. I > >> haven't > >>> been able to make NetworkManager pick up the changes on RH systems so > >> far. > >> > >> So we do use NetworkManager in the OpenDev images, and we do not see > >> NetworkManager starting before glean. > >> > > > > Okay, thanks for confirming. Maybe it's related to how IPA is built? It's > > not exactly a normal image after all, although it's pretty close to one. > > > > > >> > >> The way it should work is that simple-init in dib installs glean to > >> the image. That runs the glean install script (use --use-nm argument > >> if DIB_SIMPLE_INIT_NETWORKMANAGER, which is default on centos/fedora) > >> which installs two things; udev rules and a systemd handler. > >> > > > > I have checked that these are installed, but I don't know how to verify a > > udev rule. > > > > > >> > >> The udev is pretty simple [1] and should add a "Wants" for each net > >> device; e.g. eth1 would match and create a Wants glean at eth1.service, > >> which then matches [2] which should write out the ifcfg config file. > >> After this, NetworkManager should start, notice the config file for > >> the interface and bring it up. > >> > > > > Yeah, I definitely see logging from NetworkManager DHCP before this service > > is run (i.e. before the output from Glean). > > > > > >> > >>> Do you maybe have any hints how to proceed? I'd be curious to know how > >>> static IP assignment works in the infra setup. Do you have images with > >>> NetworkManager there? Do you use the simple-init element? > >> > >> As noted yes we use this. Really only in two contexts; it's Rackspace > >> that doesn't have DHCP so we have to setup the interface statically > >> from the configdrive data. Other clouds all provide DHCP, which is > >> used when there's no configdrive data. > >> > >> Here is a systemd-analyze from one of our Centos nodes if it helps: > >> > > > >> graphical.target @18.403s > >> └─multi-user.target @18.403s > >> └─unbound.service @5.467s +12.934s > >> └─network.target @5.454s > >> └─NetworkManager.service @5.339s +112ms > >> └─network-pre.target @5.334s > >> └─glean at ens3.service @4.227s +1.102s > >> └─basic.target @4.167s > >> └─sockets.target @4.166s > >> └─iscsiuio.socket @4.165s > >> └─sysinit.target @4.153s > >> └─systemd-udev-settle.service @1.905s +2.245s > >> └─systemd-udev-trigger.service @1.242s +659ms > >> └─systemd-udevd-control.socket @1.239s > >> └─system.slice > >> > > > > # systemd-analyze critical-chain > > multi-user.target @2min 6.301s > > └─tuned.service @1min 32.273s +34.024s > > └─network.target @1min 31.590s > > └─network-pre.target @1min 31.579s > > └─glean at enp1s0.service @36.594s +54.952s > > └─system-glean.slice @36.493s > > └─system.slice @4.083s > > └─-.slice @4.080s > > > > # systemd-analyze critical-chain NetworkManager.service > > NetworkManager.service +9.287s > > └─network-pre.target @1min 31.579s > > └─glean at enp1s0.service @36.594s +54.952s > > └─system-glean.slice @36.493s > > └─system.slice @4.083s > > └─-.slice @4.080s > > > > # cat /etc/sysconfig/network-scripts/ifcfg-enp1s0 > > # Automatically generated, do not edit > > DEVICE=enp1s0 > > BOOTPROTO=static > > HWADDR=52:54:00:1f:79:7e > > IPADDR=192.168.122.42 > > NETMASK=255.255.255.0 > > ONBOOT=yes > > NM_CONTROLLED=yes > > > > # ip addr > > ... > > 2: enp1s0: mtu 1500 qdisc fq_codel state > > UP group default qlen 1000 > > link/ether 52:54:00:1f:79:7e brd ff:ff:ff:ff:ff:ff > > inet 192.168.122.77/24 brd 192.168.122.255 scope global dynamic > > noprefixroute enp1s0 > > valid_lft 42957sec preferred_lft 42957sec > > inet6 fe80::f182:7fb4:7a39:eb7b/64 scope link noprefixroute > > valid_lft forever preferred_lft forever > > > > > >> At a guess; I feel like the udev bits are probably not happening > >> correctly in your case? That's important to get the glean@ > >> service in the chain to pre-create the config file > >> > > > > It seems that the ordering is correct and the interface service is > > executed, but the IP address is nonetheless wrong. > > > > Can it be related to how long glean takes to run in my case (54 seconds vs > > 1 second in your case)? > > > > Dmitry > > > > > >> > >> -i > >> > >> [1] > >> https://opendev.org/opendev/glean/src/branch/master/glean/init/glean-udev.rules > >> [2] > >> https://opendev.org/opendev/glean/src/branch/master/glean/init/glean-nm at .service > >> > >> > > > -- Slawek Kaplonski Principal Software Engineer Red Hat From skaplons at redhat.com Wed Nov 25 14:57:48 2020 From: skaplons at redhat.com (Slawek Kaplonski) Date: Wed, 25 Nov 2020 15:57:48 +0100 Subject: [neutron] [nova] [ussuri] IP of the VM at the provider network is different than the one registered at the Openstack controller In-Reply-To: References: Message-ID: <20201125145748.yfg4si4tfe46qctg@p1.localdomain> Hi, On Wed, Nov 25, 2020 at 02:52:56PM +0200, Pavlos Basaras wrote: > Hello, > > Setup: > i follow the main instruction for deploying openstack for learning purposes. > I can successfully deploy vms in an internal network, and also connect them > to a router that gives internet access using floating ips etc. > My setup is based on ubuntu 18. I have virtualbox for deploying controller > (10.0.0.11) and compute (10.0.0.31) etc. > I have host only adapters at virtual box (dhcp enabled) for the two > networks: mgmt: 10.0.0.0/24 and provider 203.0.111.0/24 as per the default > instructions, and i use iptables to NAT the vms. > > Problem: > When following the instructions from > https://docs.openstack.org/install-guide/launch-instance-provider.html the > vm is deployed successfully but the ip that it is assigned is different > from the one that the controller has. > It seems that there are more than one dhcp instances running? How can i > debug this? I'm not sure if I understand correctly but do You want to have Your virtualbox to run as DHCP server for vms run by OpenStack? Neutron has own dhcp agent and that is providing IPs to Your VMs according to the IP Allocation done by neutron. IPs are form the subnet created in the network to which Your vm is plugged. > > > Any advice? > > all the best, > Pavlos. -- Slawek Kaplonski Principal Software Engineer Red Hat From fungi at yuggoth.org Wed Nov 25 15:11:23 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 25 Nov 2020 15:11:23 +0000 Subject: [neutron][operators][all][security-sig] Watch out for updates of stable/train and stable/stein releases in Neutron In-Reply-To: <20201125090022.4iouend2rxkpkjmg@p1.localdomain> References: <20201124215831.bryboz64jypo75eq@p1.localdomain> <20201124225355.b7ft46d326dlwpzs@p1.localdomain> <20201125085823.5wdfjn2kf2jnyvah@p1.localdomain> <20201125090022.4iouend2rxkpkjmg@p1.localdomain> Message-ID: <20201125151122.kj3xedhsymgk53jw@yuggoth.org> On 2020-11-25 10:00:22 +0100 (+0100), Slawek Kaplonski wrote: > On Wed, Nov 25, 2020 at 09:58:23AM +0100, Slawek Kaplonski wrote: > > On Wed, Nov 25, 2020 at 08:47:03AM +0000, Tobias Urdin wrote: > > > > > So to be clear in our case here, we are running 15.1.0 for > > > neutron-server and 15.3.0 for neutron agents. > > > > > > That means that the agents does work but there is a security > > > issue,as described regarding allowed address-pair, have I > > > understood it correctly? > > > > Yes, as it may have errors while applying SG rules. > > But one more thing. I'm not really sure if that is security issue > TBH. By default neutron is dropping traffic to/from instances and > You need to allow some kind of traffic by setting security group > rules. So if rules will not be applied, some traffic will be > dropped but nothing unwanted shouldn't be allowed. [...] I think maybe he was referring specifically to https://launchpad.net/bugs/1867119 (which really should have been marked as a duplicate of https://launchpad.net/bugs/1793029 and the older one reopened instead). In short, it describes an intended/expected behavior, and any potential changes to make it less of a potential foot-cannon were deemed in 1793029 to constitute an API break, so would not have been safe to backport to stable branches. Instead the behavior was highlighted with a warning here: https://docs.openstack.org/api-ref/network/v2/index.html#allowed-address-pairs Probably if 1867119 had been redirected to 1793029 as a duplicate and the discussion continued there, attempts to backport the "fix" for it would have gotten shut down quickly, but that's all hindsight now I suppose. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From oliver.wenz at dhbw-mannheim.de Wed Nov 25 15:21:11 2020 From: oliver.wenz at dhbw-mannheim.de (Oliver Wenz) Date: Wed, 25 Nov 2020 16:21:11 +0100 Subject: [neutron][openstack-ansible] Instances can only connect to provider-net via tenant-net but not directly In-Reply-To: References: Message-ID: <6f36eb42-5904-a7b5-cc4d-7768c05a58b4@dhbw-mannheim.de> > First of all I'd suggest checking `openstack network agent list` and ensure that lxb agent is present there up and healthy. > Next I'd check nova-scheduler log (journalctl eventually) as it might have more insights. linuxbridge agent is up and healthy and the nova-scheduler log doesn't show any errors either > Please check in neutron server logs for the problems with binding port Indeed, running journalctl and grepping for the instance id shows an error (last lines): journalctl -u neutron-server -n 300 | grep 33c662c2-99d6-40fb-a716-118ad8b3b193 Nov 25 15:06:58 infra1-neutron-server-container-cbf4b105 neutron-server[88]: 2020-11-25 15:06:58.738 88 INFO neutron.wsgi [req-e5b7df6c-bfde-438a-bbb1-f2713b63e16b 920e739127a14018a55fb4422b0885e7 0f14905dab5546e0adec2b56c0f6be88 - default default] 192.168.110.128,192.168.110.201 "GET /v2.0/ports?device_id=33c662c2-99d6-40fb-a716-118ad8b3b193 HTTP/1.1" status: 200 len: 205 time: 0.3313231 Nov 25 15:07:04 infra1-neutron-server-container-cbf4b105 neutron-server[89]: 2020-11-25 15:07:04.782 89 INFO neutron.wsgi [req-9bdadc77-27d9-4f9d-86b5-349b598b1ba4 eaf8235312004e2da519b54d196f5415 474b7aa9b7894d6782402135c6ef4c2a - default default] 192.168.110.205,192.168.110.201 "GET /v2.0/ports?tenant_id=0f14905dab5546e0adec2b56c0f6be88&device_id=33c662c2-99d6-40fb-a716-118ad8b3b193 HTTP/1.1" status: 200 len: 1084 time: 0.0956030 Nov 25 15:07:05 infra1-neutron-server-container-cbf4b105 neutron-server[89]: 2020-11-25 15:07:05.020 89 INFO neutron.notifiers.nova [-] Nova event response: {'name': 'network-changed', 'server_uuid': '33c662c2-99d6-40fb-a716-118ad8b3b193', 'tag': '1e24a151-bd29-47f8-914b-05c66587541b', 'status': 'completed', 'code': 200} Nov 25 15:07:05 infra1-neutron-server-container-cbf4b105 neutron-server[89]: 2020-11-25 15:07:05.781 89 INFO neutron.wsgi [req-9b729386-4847-4be3-80fa-dce244435ddd eaf8235312004e2da519b54d196f5415 474b7aa9b7894d6782402135c6ef4c2a - default default] 192.168.110.205,192.168.110.201 "GET /v2.0/ports?tenant_id=0f14905dab5546e0adec2b56c0f6be88&device_id=33c662c2-99d6-40fb-a716-118ad8b3b193 HTTP/1.1" status: 200 len: 1084 time: 0.1147285 Nov 25 15:12:12 infra1-neutron-server-container-cbf4b105 neutron-server[89]: 2020-11-25 15:12:12.445 89 INFO neutron.wsgi [req-15cbcb76-04cd-4813-b1f9-d7f6596e14bf 920e739127a14018a55fb4422b0885e7 0f14905dab5546e0adec2b56c0f6be88 - default default] 192.168.110.205,192.168.110.201 "GET /v2.0/ports?device_id=33c662c2-99d6-40fb-a716-118ad8b3b193 HTTP/1.1" status: 200 len: 1085 time: 0.4594653 Nov 25 15:12:14 infra1-neutron-server-container-cbf4b105 neutron-server[83]: 2020-11-25 15:12:14.453 83 WARNING neutron.notifiers.nova [-] Nova event: {'server_uuid': '33c662c2-99d6-40fb-a716-118ad8b3b193', 'name': 'network-vif-deleted', 'tag': '1e24a151-bd29-47f8-914b-05c66587541b', 'status': 'failed', 'code': 422} returned with failed status Kind regards, Oliver From jlibosva at redhat.com Mon Nov 23 12:39:18 2020 From: jlibosva at redhat.com (Jakub Libosvar) Date: Mon, 23 Nov 2020 13:39:18 +0100 Subject: [neutron] Bug deputy report November 16 - 22 Message-ID: <7b78ab8a-1223-4627-89d1-d8e42891ffac@redhat.com> Hi all, I was the bug deputy for the last week, here is the report: Critical * Failure in test_l2_agent_restart(OVS,Flat network) https://bugs.launchpad.net/neutron/+bug/1904897 This is failing on the gate occasionally Needs an assignee High * GRE tunnels over IPv6 are created in wrong way https://bugs.launchpad.net/neutron/+bug/1904564 Assigned to: Slawek Patch review pending: https://review.opendev.org/c/openstack/neutron/+/763204/ * [OVN] Metadata namespace checksum error with DPDK https://bugs.launchpad.net/neutron/+bug/1904871 Assigned to: Rodolfo Medium * [ovn] Don't include IP addresses for OVN ports if both port security and DHCP are disabled https://bugs.launchpad.net/neutron/+bug/1904412 Assigned to: Elvira Patch review pending: https://review.opendev.org/c/openstack/neutron/+/763567/ * Designate driver: allow_reverse_dns_lookup doesn't works if dns_domain zone wasn't created https://bugs.launchpad.net/neutron/+bug/1904559 Reporter offered a patch but hasn't sent yet * [OVN] Inconsistent "flooding to unregistered" IGMP configuration  https://bugs.launchpad.net/neutron/+bug/1904399 Assigned to: Lucas Patch review pending: https://review.opendev.org/c/openstack/neutron/+/762818/ Wishlist * "gateway" option is not honored when creating a subnet with subnet pool https://bugs.launchpad.net/neutron/+bug/1904436 [RFE] Extend neutron-metadata-agent to support to proxy multiple external services https://bugs.launchpad.net/neutron/+bug/1905115 This is an RFE, so far marked as wishlist, should be discussed by the drivers team. Undecided * Enforce security group cleanup (Resources leaks) https://bugs.launchpad.net/neutron/+bug/1904694 It was not clear to me where does the error come from, I assumed tempest. * Neutron – it’s possible to delete router’s port related to external gateway https://bugs.launchpad.net/neutron/+bug/1904751 * neutron-dynamic-routing reported as not alive after adding BGP Peer to BGP Speaker https://bugs.launchpad.net/neutron/+bug/1904869 It seems to me like a configuration issue, agent missing rabbitmq settings. Invalid * Neutron – it’s possible to delete router’s port related to external gateway There is a patch: https://review.opendev.org/#/c/763198/ It's claimed this patch is reproducing the issue but the patch fails elsewhere. I don't think this report is valid. From monadt at protonmail.com Tue Nov 24 13:41:07 2020 From: monadt at protonmail.com (monadt) Date: Tue, 24 Nov 2020 13:41:07 +0000 Subject: [magnum] Can not deploy a cluster using Fedora CoreOS 32 Message-ID: I am trying to use Magnum on Openstack that was deployed using kolla-ansible. The instance is completely private (so floating IPs are only accessible inside a VPN network) - not sure if this is a problem. The deployment looks as follows: Openstack Nodes: Ubuntu 20.04 Kolla-Ansible version: '10.1.0' kolla_base_distro: "ubuntu" openstack_release: "ussuri" I could successfully deploy the required magnum services and created a cluster template using the magnum cli as follows: openstack coe cluster template create kubernetes-cluster-template --image fedora-coreos-32 --external-network public-external --dns-nameserver 1.1.1.1 --master-flavor m1.small --flavor m1.small --docker-storage-driver overlay --coe kubernetes I am using the Fedora CoreOS 32 release (and uploaded the image like this): openstack image create --disk-format=qcow2 --container-format=bare --file=fedora-coreos-32.20201104.3.0-openstack.x86_64.qcow2 --property os_distro='fedora-coreos' fedora-coreos-32 I made sure to set the os_distro as stated in the repository when using fedora coreos. When I now try to create a cluster (openstack coe cluster create kubernetes-cluster --cluster-template kubernetes-cluster-template --master-count 1 --node-count 1 --keypair mykey) all the heat resources start spinning up, but the kube-masters resource will never come up. While debugging it seems to hang during the following step inside the heat-container-agent: + '[' ok = ok ']' + kubectl patch node kubernetes-cluster-flfrufngma6x-master-0 --patch '{"metadata": {"labels": {"node-role.kubernetes.io/master": ""}}}' error: no configuration has been provided, try setting KUBERNETES_MASTER environment variable + echo 'Trying to label master node with node-role.kubernetes.io/master=""' + sleep 5s Trying to label master node with node-role.kubernetes.io/master="" I also didn't find a way to set the KUBERNETES_MASTER environment variable from the outside. I assume there is no other supported distribution given that Fedora Atomic and non-Fedora CoreOS do no longer exist? Sent with [ProtonMail](https://protonmail.com) Secure Email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From goel.nitish10 at gmail.com Wed Nov 25 04:12:31 2020 From: goel.nitish10 at gmail.com (Nitish Goel) Date: Wed, 25 Nov 2020 09:42:31 +0530 Subject: XDG_SESSION_TYPE error on devstack installation Message-ID: Hi Team, I'm trying to install a devstack on a ubuntu 18.04 VM having python 3.6.9 but getting below error. Any suggestions? python - 3.6.9 stack user with sudo access. pip version - pip 20.2.4 from /usr/local/lib/python3.6/dist-packages/pip (python 3.6) https://stackoverflow.com/questions/64989221/xdg-session-type-error-on-devstack-installation NFO keystone.cmd.bootstrap [None req-f46e9c41-1b14-4e5b-82b2-ada81e8b0dcd None None] Created region RegionOne INFO keystone.cmd.bootstrap [None req-f46e9c41-1b14-4e5b-82b2-ada81e8b0dcd None None] Created public endpoint http://10.61.62.241/identity INFO keystone.cmd.bootstrap [None req-f46e9c41-1b14-4e5b-82b2-ada81e8b0dcd None None] Created admin endpoint http://10.61.62.241/identity +./stack.sh:main:1084 create_keystone_accounts +lib/keystone:create_keystone_accounts:314 local admin_project ++lib/keystone:create_keystone_accounts:315 oscwrap project show admin -f value -c id Traceback (most recent call last): File "/usr/local/bin/openstack", line 5, in from openstackclient.shell import main File "/usr/local/lib/python3.6/dist-packages/openstackclient/shell.py", line 24, in from osc_lib import shell File "/usr/local/lib/python3.6/dist-packages/osc_lib/shell.py", line 24, in from cliff import app File "/usr/local/lib/python3.6/dist-packages/cliff/app.py", line 24, in import cmd2 File "/usr/local/lib/python3.6/dist-packages/cmd2/__init__.py", line 30, in from .cmd2 import Cmd File "/usr/local/lib/python3.6/dist-packages/cmd2/cmd2.py", line 48, in from .clipboard import can_clip, get_paste_buffer, write_to_paste_buffer File "/usr/local/lib/python3.6/dist-packages/cmd2/clipboard.py", line 12, in _ = pyperclip.paste() File "/usr/local/lib/python3.6/dist-packages/pyperclip/__init__.py", line 680, in lazy_load_stub_paste copy, paste = determine_clipboard() File "/usr/local/lib/python3.6/dist-packages/pyperclip/__init__.py", line 568, in determine_clipboard os.environ["XDG_SESSION_TYPE"] == "wayland" and File "/usr/lib/python3.6/os.py", line 669, in __getitem__ raise KeyError(key) from None KeyError: 'XDG_SESSION_TYPE' ++functions-common:oscwrap:2346 return 1 +lib/keystone:create_keystone_accounts:315 admin_project= +lib/keystone:create_keystone_accounts:1 exit_trap +./stack.sh:exit_trap:491 local r=1 ++./stack.sh:exit_trap:492 jobs -p +./stack.sh:exit_trap:492 jobs= +./stack.sh:exit_trap:495 [[ -n '' ]] +./stack.sh:exit_trap:501 '[' -f /tmp/tmp.LRWsRkTTkV ']' +./stack.sh:exit_trap:502 rm /tmp/tmp.LRWsRkTTkV +./stack.sh:exit_trap:506 kill_spinner +./stack.sh:kill_spinner:401 '[' '!' -z '' ']' +./stack.sh:exit_trap:508 [[ 1 -ne 0 ]] +./stack.sh:exit_trap:509 echo 'Error on exit' Error on exit +./stack.sh:exit_trap:511 type -p generate-subunit +./stack.sh:exit_trap:512 generate-subunit 1606228299 592 fail +./stack.sh:exit_trap:514 [[ -z /opt/stack/logs ]] +./stack.sh:exit_trap:517 /usr/bin/python3.6 /opt/stack/devstack/tools/worlddump.py -d /opt/stack/logs +./stack.sh:exit_trap:526 exit 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbasaras at gmail.com Mon Nov 23 13:52:56 2020 From: pbasaras at gmail.com (Pavlos Basaras) Date: Mon, 23 Nov 2020 15:52:56 +0200 Subject: [neutron] Cannot deploy instance in provider network openstack Ussuri -- network fails In-Reply-To: <20201123115237.moahcpvoreslx4wk@p1.localdomain> References: <20201123115237.moahcpvoreslx4wk@p1.localdomain> Message-ID: Hello, I double checked the configuration with: https://docs.openstack.org/neutron/ussuri/install/compute-install-ubuntu.html , it looks ok, i think. attached the log from the compute node. Do you need any other log files ? As i am a newbie i don't really know how to "open an LP bug " all the best Pavlos. On Mon, Nov 23, 2020 at 1:52 PM Slawek Kaplonski wrote: > Hi, > > On Mon, Nov 23, 2020 at 12:11:55PM +0200, Pavlos Basaras wrote: > > Hello, > > > > i am new to Openstack. > > > > I have followed the instructions from > > https://docs.openstack.org/install-guide/ to install openstack Ussuri > where > > i use a controller node and a compute node (i can ping each other and > > access the internet from both nodes through the mgmt iface). > > > > I use ubuntu 18.04 for all components. > > > > I have configured the network option 2, seems to work fine: > > > > openstack network agent list > > > +--------------------------------------+--------------------+------------+-------------------+-------+-------+---------------------------+ > > | ID | Agent Type | Host > | > > Availability Zone | Alive | State | Binary | > > > +--------------------------------------+--------------------+------------+-------------------+-------+-------+---------------------------+ > > | 2d8c3a89-32c4-4b97-aa4f-ca19db53b24f | L3 agent | controller > | > > nova | :-) | UP | neutron-l3-agent | > > | 413cd13d-88d7-45ce-8b2e-26fdb265740f | Metadata agent | controller > | > > None | :-) | UP | neutron-metadata-agent | > > | 42f57bee-63b3-44e6-9392-939ece98719d | Linux bridge agent | compute > | > > None | :-) | UP | neutron-linuxbridge-agent | > > | 4a787a09-04aa-4350-bd32-0c0177ed06a1 | DHCP agent | controller > | > > nova | :-) | UP | neutron-dhcp-agent | > > | fdafc337-7581-4ecd-b175-810713a25e1f | Linux bridge agent | controller > | > > None | :-) | UP | neutron-linuxbridge-agent | > > > +--------------------------------------+--------------------+------------+-------------------+-------+-------+---------------------------+ > > > > If i try to bring up instances connected by an internal network, they are > > successfully deployed. > > > > When i use the provider network to bring up an instance with the command: > > openstack server create --flavor m1.tiny --image cirros034 --nic > > net-id=4463e4a7-3b06-46d9-b24f-3e2e7867ee96 > > --security-group=5cf380e5-efb3-48b3-b8e9-095b1ebd817d provider-instance > > > > the instance fails to be instantiated because the network cannot be > > deployed. > > > > I noticed two points from the neutron-linuxbridge-agent.log file at the > > compute node (the logs at the controller seem fine): > > > > 1) ERROR neutron.plugins.ml2.drivers.agent._common_agent > > pyroute2.netlink.exceptions.NetlinkError: (13, 'Permission denied') > > This sounds like maybe some issue with usage of sudo by user which runs > neutron-linuxbridge-agent. Is it configured properly? > > > 2) INFO neutron.plugins.ml2.drivers.agent._common_agent > > [req-816902d4-6581-49c1-939a-6ea69b437c99 - - - - -] Linux bridge agent > > Agent out of sync with plugin! -- not sure if this one is a problem. > > This is probably just a result of above error. But to be sure I would need > to > see whole log. > > If You will still have such issue, please open LP bug and attach Your logs > there. In such way it should be maybe easier to investigate what is going > on > there. > > In Ussuri we are running CI job neutron-tempest-plugin-scenario-linuxbridge > which deploys neutron-linuxbridge-agent and all works fine there. You can > check > that e.g. on > https://zuul.opendev.org/t/openstack/build/441182cb87fd47daa34d5018fc2eb9ab > > > > > One part that i am not sure is the following configuration since i am on > > ubuntu 18 and not ubuntu 16: > > > > # The provider network interface > > auto INTERFACE_NAME > > iface INTERFACE_NAME inet manual > > up ip link set dev $IFACE up > > down ip link set dev $IFACE down > > > > I did not include this part in my file since its ubuntu 18, and netplan > > does not have an equivalent (i think) option. I have this netplan config > > > > enp0s8: --> mgmt > > dhcp4: false > > addresses: [10.0.0.31/24] > > gateway4: 10.0.0.1 > > nameservers: > > addresses: [8.8.8.8, 8.8.4.4] > > enp0s9: --> provider > > dhcp4: false > > > > > > > > any advice? > > > > all the best, > > Pavlos Basaras > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: neutron-linuxbridge-agent.log Type: text/x-log Size: 8452598 bytes Desc: not available URL: From strigazi at gmail.com Wed Nov 25 15:51:02 2020 From: strigazi at gmail.com (Spyros Trigazis) Date: Wed, 25 Nov 2020 16:51:02 +0100 Subject: [magnum] Can not deploy a cluster using Fedora CoreOS 32 In-Reply-To: References: Message-ID: Try https://hub.docker.com/layers/openstackmagnum/heat-container-agent/ussuri-stable-1/images/sha256-a6cff99d9b468d1e1770a74853e83a5688d73a714eeae22463b1c8af2001bf1d?context=explore For heat_container_agent_tag Spyros On Wed, Nov 25, 2020 at 4:48 PM monadt wrote: > I am trying to use Magnum on Openstack that was deployed using > kolla-ansible. > > The instance is completely private (so floating IPs are only accessible > inside a VPN network) - not sure if this is a problem. > > The deployment looks as follows: > > Openstack Nodes: Ubuntu 20.04 > Kolla-Ansible version: '10.1.0' > kolla_base_distro: "ubuntu" > openstack_release: "ussuri" > > I could successfully deploy the required magnum services and created a > cluster template using the magnum cli as follows: > > openstack coe cluster template create kubernetes-cluster-template --image > fedora-coreos-32 --external-network public-external --dns-nameserver > 1.1.1.1 --master-flavor m1.small --flavor m1.small --docker-storage-driver > overlay --coe kubernetes > > I am using the Fedora CoreOS 32 release (and uploaded the image like this): > > openstack image create --disk-format=qcow2 --container-format=bare > --file=fedora-coreos-32.20201104.3.0-openstack.x86_64.qcow2 --property > os_distro='fedora-coreos' fedora-coreos-32 > > I made sure to set the os_distro as stated in the repository when using > fedora coreos. > > When I now try to create a cluster (openstack coe cluster create > kubernetes-cluster --cluster-template kubernetes-cluster-template > --master-count 1 --node-count 1 --keypair mykey) all the heat resources > start spinning up, but the kube-masters resource will never come up. > > While debugging it seems to hang during the following step inside the > heat-container-agent: > > + '[' ok = ok ']' > + kubectl patch node kubernetes-cluster-flfrufngma6x-master-0 --patch > '{"metadata": {"labels": {"node-role.kubernetes.io/master": ""}}}' > error: no configuration has been provided, try setting KUBERNETES_MASTER > environment variable > + echo 'Trying to label master node with node-role.kubernetes.io/master= > ""' > + sleep 5s > Trying to label master node with node-role.kubernetes.io/master="" > > I also didn't find a way to set the KUBERNETES_MASTER environment variable > from the outside. > > I assume there is no other supported distribution given that Fedora Atomic > and non-Fedora CoreOS do no longer exist? > > > Sent with ProtonMail Secure Email. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Wed Nov 25 16:21:35 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 25 Nov 2020 16:21:35 +0000 Subject: XDG_SESSION_TYPE error on devstack installation In-Reply-To: References: Message-ID: <20201125162017.doki5lrgm2is67lb@yuggoth.org> On 2020-11-25 09:42:31 +0530 (+0530), Nitish Goel wrote: > I'm trying to install a devstack on a ubuntu 18.04 VM [...] Not an exact answer to your question, but in order to save you other headaches: you don't specify what version of DevStack you're installing; if Victoria or newer then it's not tested to work on Ubuntu 18.04 LTS. https://governance.openstack.org/tc/reference/runtimes/victoria.html For recent DevStack versions make sure to use an appropriately tested distribution (if Victoria, then one of Ubuntu 20.04, CentOS 8, or openSUSE Leap 15). -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From rosmaita.fossdev at gmail.com Wed Nov 25 16:22:41 2020 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Wed, 25 Nov 2020 11:22:41 -0500 Subject: [cinder] wallaby R-18 virtual mid-cycle on 9 december Message-ID: <4c589c94-12b3-689c-68be-32cf6011692e@gmail.com> As voted upon at today's weekly meeting, the Cinder Wallaby R-18 virtual mid-cycle will be held: DATE: WEDNESDAY 9 DECEMBER 2020 TIME: 1400-1600 UTC LOCATION: https://bluejeans.com/3228528973 The meeting will be recorded. Please add topics to the mid-cycle etherpad: https://etherpad.opendev.org/p/cinder-wallaby-mid-cycles cheers, brian From mark at stackhpc.com Wed Nov 25 16:25:13 2020 From: mark at stackhpc.com (Mark Goddard) Date: Wed, 25 Nov 2020 16:25:13 +0000 Subject: [magnum] Can not deploy a cluster using Fedora CoreOS 32 In-Reply-To: References: Message-ID: Monadt, I proposed some basic docs for using magnum with Kolla Ansible [1]. They don't cover the cluster template, but they might be useful to you anyway. [1] https://review.opendev.org/c/openstack/kolla-ansible/+/763770 On Wed, 25 Nov 2020 at 15:49, monadt wrote: > > I am trying to use Magnum on Openstack that was deployed using kolla-ansible. > > The instance is completely private (so floating IPs are only accessible inside a VPN network) - not sure if this is a problem. > > The deployment looks as follows: > > Openstack Nodes: Ubuntu 20.04 > Kolla-Ansible version: '10.1.0' > kolla_base_distro: "ubuntu" > openstack_release: "ussuri" > > I could successfully deploy the required magnum services and created a cluster template using the magnum cli as follows: > > openstack coe cluster template create kubernetes-cluster-template --image fedora-coreos-32 --external-network public-external --dns-nameserver 1.1.1.1 --master-flavor m1.small --flavor m1.small --docker-storage-driver overlay --coe kubernetes > > I am using the Fedora CoreOS 32 release (and uploaded the image like this): > > openstack image create --disk-format=qcow2 --container-format=bare --file=fedora-coreos-32.20201104.3.0-openstack.x86_64.qcow2 --property os_distro='fedora-coreos' fedora-coreos-32 > > I made sure to set the os_distro as stated in the repository when using fedora coreos. > > When I now try to create a cluster (openstack coe cluster create kubernetes-cluster --cluster-template kubernetes-cluster-template --master-count 1 --node-count 1 --keypair mykey) all the heat resources start spinning up, but the kube-masters resource will never come up. > > While debugging it seems to hang during the following step inside the heat-container-agent: > > + '[' ok = ok ']' > + kubectl patch node kubernetes-cluster-flfrufngma6x-master-0 --patch '{"metadata": {"labels": {"node-role.kubernetes.io/master": ""}}}' > error: no configuration has been provided, try setting KUBERNETES_MASTER environment variable > + echo 'Trying to label master node with node-role.kubernetes.io/master=""' > + sleep 5s > Trying to label master node with node-role.kubernetes.io/master="" > > I also didn't find a way to set the KUBERNETES_MASTER environment variable from the outside. > > I assume there is no other supported distribution given that Fedora Atomic and non-Fedora CoreOS do no longer exist? > > > Sent with ProtonMail Secure Email. > From balazs.gibizer at est.tech Wed Nov 25 16:37:07 2020 From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer) Date: Wed, 25 Nov 2020 17:37:07 +0100 Subject: XDG_SESSION_TYPE error on devstack installation In-Reply-To: References: Message-ID: On Wed, Nov 25, 2020 at 09:42, Nitish Goel wrote: > Hi Team, > > I'm trying to install a devstack on a ubuntu 18.04 VM having python > 3.6.9 but getting below error. Any suggestions? > python - 3.6.9 > stack user with sudo access. > pip version - pip 20.2.4 from > /usr/local/lib/python3.6/dist-packages/pip (python 3.6) > https://stackoverflow.com/questions/64989221/xdg-session-type-error-on-devstack-installation > NFO keystone.cmd.bootstrap [None > req-f46e9c41-1b14-4e5b-82b2-ada81e8b0dcd None None] Created region > RegionOne > INFO keystone.cmd.bootstrap [None > req-f46e9c41-1b14-4e5b-82b2-ada81e8b0dcd None None] Created public > endpoint http://10.61.62.241/identity > INFO keystone.cmd.bootstrap [None > req-f46e9c41-1b14-4e5b-82b2-ada81e8b0dcd None None] Created admin > endpoint http://10.61.62.241/identity > > > +./stack.sh:main:1084 create_keystone_accounts > +lib/keystone:create_keystone_accounts:314 local admin_project > ++lib/keystone:create_keystone_accounts:315 oscwrap project show > admin -f value -c id > Traceback (most recent call last): > File "/usr/local/bin/openstack", line 5, in > from openstackclient.shell import main > File > "/usr/local/lib/python3.6/dist-packages/openstackclient/shell.py", > line 24, in > from osc_lib import shell > File "/usr/local/lib/python3.6/dist-packages/osc_lib/shell.py", > line 24, in > from cliff import app > File "/usr/local/lib/python3.6/dist-packages/cliff/app.py", line > 24, in > import cmd2 > File "/usr/local/lib/python3.6/dist-packages/cmd2/__init__.py", > line 30, in > from .cmd2 import Cmd > File "/usr/local/lib/python3.6/dist-packages/cmd2/cmd2.py", line > 48, in > from .clipboard import can_clip, get_paste_buffer, > write_to_paste_buffer > File "/usr/local/lib/python3.6/dist-packages/cmd2/clipboard.py", > line 12, in > _ = pyperclip.paste() > File > "/usr/local/lib/python3.6/dist-packages/pyperclip/__init__.py", line > 680, in lazy_load_stub_paste > copy, paste = determine_clipboard() > File > "/usr/local/lib/python3.6/dist-packages/pyperclip/__init__.py", line > 568, in determine_clipboard > os.environ["XDG_SESSION_TYPE"] == "wayland" and > File "/usr/lib/python3.6/os.py", line 669, in __getitem__ > raise KeyError(key) from None > KeyError: 'XDG_SESSION_TYPE' > > ++functions-common:oscwrap:2346 return 1 > +lib/keystone:create_keystone_accounts:315 admin_project= > +lib/keystone:create_keystone_accounts:1 exit_trap > +./stack.sh:exit_trap:491 local r=1 > ++./stack.sh:exit_trap:492 jobs -p > +./stack.sh:exit_trap:492 jobs= > +./stack.sh:exit_trap:495 [[ -n '' ]] > +./stack.sh:exit_trap:501 '[' -f /tmp/tmp.LRWsRkTTkV > ']' > +./stack.sh:exit_trap:502 rm /tmp/tmp.LRWsRkTTkV > +./stack.sh:exit_trap:506 kill_spinner > +./stack.sh:kill_spinner:401 '[' '!' -z '' ']' > +./stack.sh:exit_trap:508 [[ 1 -ne 0 ]] > +./stack.sh:exit_trap:509 echo 'Error on exit' > Error on exit > +./stack.sh:exit_trap:511 type -p generate-subunit > +./stack.sh:exit_trap:512 generate-subunit > 1606228299 592 fail > +./stack.sh:exit_trap:514 [[ -z /opt/stack/logs ]] > +./stack.sh:exit_trap:517 /usr/bin/python3.6 > /opt/stack/devstack/tools/worlddump.py -d /opt/stack/logs > +./stack.sh:exit_trap:526 exit 1 I've seen the same error in my Ubuntu 18.04 devstack on master. I stopped digging when I saw that the code that blows are 15 months old[1]. As a workaround I did $ export XDG_SESSION_TYPE='' $ ./unstack.sh && ./stack.sh And it worked. [1] https://github.com/asweigart/pyperclip/blame/master/src/pyperclip/__init__.py#L568 Cheers, gibi From whayutin at redhat.com Wed Nov 25 16:43:57 2020 From: whayutin at redhat.com (Wesley Hayutin) Date: Wed, 25 Nov 2020 09:43:57 -0700 Subject: [tripleo][ci] Issues w/ the quay container registry Message-ID: FYI.. This is impacting jobs atm. https://bugs.launchpad.net/tripleo/+bug/1905592 Will follow up when we're clear. 0/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Wed Nov 25 17:49:58 2020 From: hberaud at redhat.com (Herve Beraud) Date: Wed, 25 Nov 2020 18:49:58 +0100 Subject: [cinder][kayobe][kolla][OSA][tripleo][release] Victoria cycle-trailing release deadline Message-ID: Hello teams with deliverables following the cycle-trailing release model! This is just a reminder about wrapping those Victoria trailing deliverables up. A few cycles ago we extended the deadline for cycle-trailing to give more time, so the actual deadline isn't until January 14, 2021: https://releases.openstack.org/wallaby/schedule.html#w-cycle-trail If things are ready sooner than that though, all the better for our downstream consumers. Just for awareness, the following cycle-trailing deliverables will need their final releases at some point in the next few months: cinderlib kayobe kolla-ansible kolla openstack-ansible os-collect-config os-refresh-config tripleo-ipsec Thanks! -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From openstack at nemebean.com Wed Nov 25 17:51:24 2020 From: openstack at nemebean.com (Ben Nemec) Date: Wed, 25 Nov 2020 11:51:24 -0600 Subject: [all][healthcheck] In-Reply-To: References: Message-ID: <15f693f8-8ba8-3765-c61b-2f9a47755956@nemebean.com> I finally found where I wrote down my notes from the discussion we had about this with nova last cycle[0]. """ Another longstanding topic that has recently come up is a standard healthcheck endpoint for OpenStack services. In the process of enabling the existing healthcheck middleware there was some question of how the healthchecks should work. Currently it's a very simple check: if the api process is running it returns success. There is also an option to suppress the healthcheck based on the existence of a file. This allows a deployer to signal a loadbalancer that the api will be going down for maintenance. However, there is obviously a lot more that goes into a given service's health. We've been discussing how to make the healthcheck more comprehensive since at least the Dublin PTG, but so far no one has been able to commit the time to make any of these plans happen. At the Denver PTG ~a year ago we agreed that the first step was to enable the healthcheck middleware by default in all services. Some progress has been made on that front, but when the change was proposed to Nova, they asked a number of the questions related to the future improvements. We revisited some of those questions at this PTG and came up with a plan to move forward that everyone seemed happy with. One concern was that we don't want to trigger resource-intensive healthchecks on unauthenticated calls to an API. In the original discussions the plan was to have healthchecks running in the background, and then the API call would just return the latest results of the async checks. A small modification to that was made in this discussion. Instead of having explicit async processes to gather this data, it will be collected on regular authenticated API calls. In this way, regularly used functionality will be healthchecked more frequently, whereas less used areas of the service will not. In addition, only authenticated users will be able to trigger potentially resource intensive healthchecks. Each project will be responsible for implementing these checks. Since each project has a different architecture only they can say what constitutes "healthy" for their service. It's possible we could provide some common code for things like messaging and database that are used in many services, but it's likely that many projects will also need some custom checks. I think that covers the major outcomes of this discussion, but we have no notes from this session so if I forgot something let me know. ;-) """ 0: http://blog.nemebean.com/content/oslo-virtual-ptg-victoria On 11/23/20 3:28 AM, Lajos Katona wrote: > Hi Erno, > Thanks for the details, we will consider these. > > Regards > Lajos > > Erno Kuvaja > ezt írta > (időpont: 2020. nov. 19., Cs, 18:14): > > On Mon, Nov 16, 2020 at 10:21 AM Lajos Katona > wrote: > > Hi, > > I send this mail out to summarize the discussion around > Healthcheck API on Neutron PTG, and start a discussion how we > can make this most valuable to the operators. > > On the Neutron PTG etherpad this topic is from L114: > https://etherpad.opendev.org/p/neutron-wallaby-ptg . > > Background: oslo_middleware provides /healthcheck API path(see > [1]), which can be used to poll by services like haproxy, and > gives a plugin mechanism to add some more complicated checks, > which can be switched on/off from config. > > The main questions: > > * Some common guidance what to present to the operators (if > you check [2] and [3] in the comments there are really good > questions/concerns) > o Perhaps the API SIG has something about healtcheck, just > I can't find it. > * What to present with and without authentication (after > checking again, I am not sure that it is possible to use > authentication for the healthcheck) > o A way forward can be to make it configurable with > default to authenticated, and give the decision to the > admin. > * During the discussion the agreement was to separate the > frontend health from the backend health and use direct > indicators (like working db connectivity, and mq > connectivity) instead of indirect indicators (like agents' > health). > > Thanks in advance for the feedback. > > [1] > https://docs.openstack.org/oslo.middleware/latest/reference/healthcheck_plugins.html > [2] https://review.opendev.org/731396 > [3] https://review.opendev.org/731554 > > Regards > Lajos Katona (lajoskatona) > > > Hi Lajos, > > Bit of background in case you don't know. The oslo healthcheck > middleware is basically a combination of healthcheck middlewares > carried within the few projects ages ago bloated with the plugin > framework I don't know of anyone ever adopted using. The main point > for those middlewares carried by Swift(I think), Glance definitely > and possibly some other projects before osloing it was to give a > place for load balancers to ping that does not necessarily need to > be logged every few seconds nor need to send the excessive amounts > of auth calls to keystone. If I recall correctly you can already > place it after keystone middleware if you prefer it being authed, I > don't know of anyone who does. > > Main purpose was to provide a way to detect if the service is not > responding or by using the disabled by file to bleed the inflight > connections for maintenance and drop them off the pool for new > requests. I think the original implementations were somewhere around > 10-20 lines of code and did just that job pretty reliably. > > Based on the plugin model, it's indeed very easy to leak information > out of that middleware and I think the plugins used need to take > that into account by careful design. I'd very much prefer not > breaking the current healthcheck and the very well stabilized API of > it that has been in use for years just because someone feels like > it's a good idea to make leaky plugins for it. Realizing that agent > status might not be the right thing to check is a good start, what > you really want to have is indication is the API service able to > take in new requests or not, not if all permutations of those > requests will succeed on the current system status. Now there are > ways to chain multiples of these middlewares with different configs > (with different endpoints) and it might be worth considering having > your plugins with detailed failure conditions on the admin side that > is not exposed to the public and just very simple yei/nei on your > public endpoint. Good luck and I hope you find the correct balance > of detail from the API and usability. > > Best, > Erno "jokke" Kuvaja > From gmann at ghanshyammann.com Wed Nov 25 20:27:53 2020 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 25 Nov 2020 14:27:53 -0600 Subject: [qa][all] New hacking 4.0.0 is available Message-ID: <17601174fd2.129c7e91f695176.4304624129155902615@ghanshyammann.com> Hello Everyone, Hacking 4.0.0 is available to use now which includes many common checks used in various projects. While upgrading to new hacking you can remove those checks definition from your repo hacking checks. Check release notes to find what all common checks are being moved from the project side to hacking: - https://docs.openstack.org/releasenotes/hacking/unreleased.html#relnotes-4-0-0 -gmann From dsneddon at redhat.com Wed Nov 25 22:38:11 2020 From: dsneddon at redhat.com (Dan Sneddon) Date: Wed, 25 Nov 2020 14:38:11 -0800 Subject: [ironic] Proposing Steve Baker (stevebaker) for ironic-core In-Reply-To: References: Message-ID: <9e63b136-284c-19c7-7ce1-9d157dde5797@redhat.com> Fantastic, Steve is great! I am on the same team as Steve and can say that he will make an excellent addition. On 11/24/20 7:02 AM, Julia Kreger wrote: > Greetings everyone, > > I would like to propose Steve Baker for ironic-core. Steve shifted > into focusing on Ironic contribution this year and he has been > actively reviewing changes during the Victoria and now Wallaby cycle. > He has brought insight, drive, and a curiosity to ask questions. Plus > he took on the challenge of removing wsme from Ironic's API which is > no small feat. > > I've run this nomination past the existing cores and everyone > responded in full support of doing so. > > So if there are no objections, I'll add Steve to ironic-core next week. > > Otherwise, Congratulations Steve! > > -Julia > -- Dan Sneddon | Senior Principal Software Engineer dsneddon at redhat.com | redhat.com/cloud dsneddon:irc | @dxs:twitter From iwienand at redhat.com Thu Nov 26 01:19:56 2020 From: iwienand at redhat.com (Ian Wienand) Date: Thu, 26 Nov 2020 12:19:56 +1100 Subject: [ironic] [infra] Making Glean work with IPA for static IP assignment In-Reply-To: References: <20201125020901.GA522326@fedora19.localdomain> Message-ID: <20201126011956.GB522326@fedora19.localdomain> On Wed, Nov 25, 2020 at 11:54:13AM +0100, Dmitry Tantsur wrote: > > # systemd-analyze critical-chain > multi-user.target @2min 6.301s > └─tuned.service @1min 32.273s +34.024s > └─network.target @1min 31.590s > └─network-pre.target @1min 31.579s > └─glean at enp1s0.service @36.594s +54.952s > └─system-glean.slice @36.493s > └─system.slice @4.083s > └─-.slice @4.080s > > # systemd-analyze critical-chain NetworkManager.service > NetworkManager.service +9.287s > └─network-pre.target @1min 31.579s > └─glean at enp1s0.service @36.594s +54.952s > └─system-glean.slice @36.493s > └─system.slice @4.083s > └─-.slice @4.080s > It seems that the ordering is correct and the interface service is > executed, but the IP address is nonetheless wrong. I agree, this seems to say to me that NetworkManager should run after network.pre-target, and glean at enp1s0 should be running before it. The glean at enp1s0.service is set as oneshot [1] which should prevent network-pre.target being reached until it exits: oneshot ... [the] service manager will consider the unit up after the main process exits. It will then start follow-up units. To the best of my knowledge the dependencies are correct; but if you go through the "git log" of the project you can find some history of us thinking ordering was correct and finding issues. > Can it be related to how long glean takes to run in my case (54 seconds vs > 1 second in your case)? The glean script doesn't run asynchronously in any way (at least not on purpose!). I can't see any way it could exit before the ifcfg file is written out. > # cat /etc/sysconfig/network-scripts/ifcfg-enp1s0 ... The way NM support works is writing out this file which is read by the NM ifcfg-rh plugin [2]. AFAIK that's built-in to NM so would not be missing, and I think you'd have to go to effort to manually edit /etc/NetworkManager/conf.d/99-main-plugins.conf to have it ignored. I'm afraid that's overall not much help. Are you sure there isn't an errant dhclient running somehow that grabs a different address? Does it get the correct address on reboot; implying the ifcfg- file is read correctly but somehow isn't in place before NetworkManager starts? -i [1] https://opendev.org/opendev/glean/src/branch/master/glean/init/glean-nm at .service#L13 [2] https://developer.gnome.org/NetworkManager/stable/nm-settings-ifcfg-rh.html From zaitcev at redhat.com Thu Nov 26 06:25:02 2020 From: zaitcev at redhat.com (Pete Zaitcev) Date: Thu, 26 Nov 2020 00:25:02 -0600 Subject: [qa][cinder][glance][swift] Gate status for swift test failing Bug#1905432 In-Reply-To: <175fda38292.ed631f76640129.5700959767027160091@ghanshyammann.com> References: <175fda38292.ed631f76640129.5700959767027160091@ghanshyammann.com> Message-ID: <20201126002502.02513611@suzdal.zaitcev.lan> On Tue, 24 Nov 2020 22:22:32 -0600 Ghanshyam Mann wrote: > As you have seen that test_create_object_with_transfer_encoding is failing consistently since 20th Nov > which is failing integrated-gate-storage and integrated-gate-object-storage jobs. > The issue is that Tempest is getting 500 from swift API, I could not find the root cause yet so decided > to disable this test for now to unlock the gate. Do you have access to the logs in the gate? A 500 in Swift should be associated with some kind of a traceback or other error. -- Pete From skaplons at redhat.com Thu Nov 26 07:43:42 2020 From: skaplons at redhat.com (Slawek Kaplonski) Date: Thu, 26 Nov 2020 08:43:42 +0100 Subject: [neutron][openstack-ansible] Instances can only connect to provider-net via tenant-net but not directly In-Reply-To: <6f36eb42-5904-a7b5-cc4d-7768c05a58b4@dhbw-mannheim.de> References: <6f36eb42-5904-a7b5-cc4d-7768c05a58b4@dhbw-mannheim.de> Message-ID: <20201126074342.am6k6mf66qgbptcf@p1.localdomain> Hi, On Wed, Nov 25, 2020 at 04:21:11PM +0100, Oliver Wenz wrote: > > First of all I'd suggest checking `openstack network agent list` and ensure that lxb agent is present there up and healthy. > > Next I'd check nova-scheduler log (journalctl eventually) as it might have more insights. > > linuxbridge agent is up and healthy and the nova-scheduler log doesn't > show any errors either > > > Please check in neutron server logs for the problems with binding port > > Indeed, running journalctl and grepping for the instance id shows an > error (last lines): > > journalctl -u neutron-server -n 300 | grep > 33c662c2-99d6-40fb-a716-118ad8b3b193 > > Nov 25 15:06:58 infra1-neutron-server-container-cbf4b105 > neutron-server[88]: 2020-11-25 15:06:58.738 88 INFO neutron.wsgi > [req-e5b7df6c-bfde-438a-bbb1-f2713b63e16b > 920e739127a14018a55fb4422b0885e7 0f14905dab5546e0adec2b56c0f6be88 - > default default] 192.168.110.128,192.168.110.201 "GET > /v2.0/ports?device_id=33c662c2-99d6-40fb-a716-118ad8b3b193 HTTP/1.1" > status: 200 len: 205 time: 0.3313231 > Nov 25 15:07:04 infra1-neutron-server-container-cbf4b105 > neutron-server[89]: 2020-11-25 15:07:04.782 89 INFO neutron.wsgi > [req-9bdadc77-27d9-4f9d-86b5-349b598b1ba4 > eaf8235312004e2da519b54d196f5415 474b7aa9b7894d6782402135c6ef4c2a - > default default] 192.168.110.205,192.168.110.201 "GET > /v2.0/ports?tenant_id=0f14905dab5546e0adec2b56c0f6be88&device_id=33c662c2-99d6-40fb-a716-118ad8b3b193 > HTTP/1.1" status: 200 len: 1084 time: 0.0956030 > Nov 25 15:07:05 infra1-neutron-server-container-cbf4b105 > neutron-server[89]: 2020-11-25 15:07:05.020 89 INFO > neutron.notifiers.nova [-] Nova event response: {'name': > 'network-changed', 'server_uuid': > '33c662c2-99d6-40fb-a716-118ad8b3b193', 'tag': > '1e24a151-bd29-47f8-914b-05c66587541b', 'status': 'completed', 'code': 200} > Nov 25 15:07:05 infra1-neutron-server-container-cbf4b105 > neutron-server[89]: 2020-11-25 15:07:05.781 89 INFO neutron.wsgi > [req-9b729386-4847-4be3-80fa-dce244435ddd > eaf8235312004e2da519b54d196f5415 474b7aa9b7894d6782402135c6ef4c2a - > default default] 192.168.110.205,192.168.110.201 "GET > /v2.0/ports?tenant_id=0f14905dab5546e0adec2b56c0f6be88&device_id=33c662c2-99d6-40fb-a716-118ad8b3b193 > HTTP/1.1" status: 200 len: 1084 time: 0.1147285 > Nov 25 15:12:12 infra1-neutron-server-container-cbf4b105 > neutron-server[89]: 2020-11-25 15:12:12.445 89 INFO neutron.wsgi > [req-15cbcb76-04cd-4813-b1f9-d7f6596e14bf > 920e739127a14018a55fb4422b0885e7 0f14905dab5546e0adec2b56c0f6be88 - > default default] 192.168.110.205,192.168.110.201 "GET > /v2.0/ports?device_id=33c662c2-99d6-40fb-a716-118ad8b3b193 HTTP/1.1" > status: 200 len: 1085 time: 0.4594653 > Nov 25 15:12:14 infra1-neutron-server-container-cbf4b105 > neutron-server[83]: 2020-11-25 15:12:14.453 83 WARNING > neutron.notifiers.nova [-] Nova event: {'server_uuid': > '33c662c2-99d6-40fb-a716-118ad8b3b193', 'name': 'network-vif-deleted', > 'tag': '1e24a151-bd29-47f8-914b-05c66587541b', 'status': 'failed', > 'code': 422} returned with failed status So this looks like issue during sending notification to Nova. You should check in Nova logs now why it returned You 422 > > > Kind regards, > Oliver > -- Slawek Kaplonski Principal Software Engineer Red Hat From pbasaras at gmail.com Thu Nov 26 11:33:24 2020 From: pbasaras at gmail.com (Pavlos Basaras) Date: Thu, 26 Nov 2020 13:33:24 +0200 Subject: [neutron] [nova] [ussuri] IP of the VM at the provider network is different than the one registered at the Openstack controller In-Reply-To: <20201125145748.yfg4si4tfe46qctg@p1.localdomain> References: <20201125145748.yfg4si4tfe46qctg@p1.localdomain> Message-ID: Hello, many thanks for your prompt response. i dissbaled the dhcp from virtualbox and now the vms get the ip from the neutron dhcp as registered by the controller. Works fine! all the best, Pavlos. On Wed, Nov 25, 2020 at 4:58 PM Slawek Kaplonski wrote: > Hi, > > On Wed, Nov 25, 2020 at 02:52:56PM +0200, Pavlos Basaras wrote: > > Hello, > > > > Setup: > > i follow the main instruction for deploying openstack for learning > purposes. > > I can successfully deploy vms in an internal network, and also connect > them > > to a router that gives internet access using floating ips etc. > > My setup is based on ubuntu 18. I have virtualbox for deploying > controller > > (10.0.0.11) and compute (10.0.0.31) etc. > > I have host only adapters at virtual box (dhcp enabled) for the two > > networks: mgmt: 10.0.0.0/24 and provider 203.0.111.0/24 as per the > default > > instructions, and i use iptables to NAT the vms. > > > > Problem: > > When following the instructions from > > https://docs.openstack.org/install-guide/launch-instance-provider.html > the > > vm is deployed successfully but the ip that it is assigned is different > > from the one that the controller has. > > It seems that there are more than one dhcp instances running? How can i > > debug this? > > I'm not sure if I understand correctly but do You want to have Your > virtualbox > to run as DHCP server for vms run by OpenStack? > Neutron has own dhcp agent and that is providing IPs to Your VMs according > to > the IP Allocation done by neutron. IPs are form the subnet created in the > network to which Your vm is plugged. > > > > > > > Any advice? > > > > all the best, > > Pavlos. > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From katonalala at gmail.com Thu Nov 26 12:35:42 2020 From: katonalala at gmail.com (Lajos Katona) Date: Thu, 26 Nov 2020 13:35:42 +0100 Subject: [all][healthcheck] In-Reply-To: <15f693f8-8ba8-3765-c61b-2f9a47755956@nemebean.com> References: <15f693f8-8ba8-3765-c61b-2f9a47755956@nemebean.com> Message-ID: Thanks Ben, This was again really helpful to understand the history of this feature, and have a glimpse of the future direction. I think with this Neutron community (and others of course) can plan now. Regards Lajos Katona (lajoskatona) Ben Nemec ezt írta (időpont: 2020. nov. 25., Sze, 18:51): > I finally found where I wrote down my notes from the discussion we had > about this with nova last cycle[0]. > > """ > Another longstanding topic that has recently come up is a standard > healthcheck endpoint for OpenStack services. In the process of enabling > the existing healthcheck middleware there was some question of how the > healthchecks should work. Currently it's a very simple check: if the api > process is running it returns success. There is also an option to > suppress the healthcheck based on the existence of a file. This allows a > deployer to signal a loadbalancer that the api will be going down for > maintenance. > > However, there is obviously a lot more that goes into a given service's > health. We've been discussing how to make the healthcheck more > comprehensive since at least the Dublin PTG, but so far no one has been > able to commit the time to make any of these plans happen. At the Denver > PTG ~a year ago we agreed that the first step was to enable the > healthcheck middleware by default in all services. Some progress has > been made on that front, but when the change was proposed to Nova, they > asked a number of the questions related to the future improvements. > > We revisited some of those questions at this PTG and came up with a plan > to move forward that everyone seemed happy with. One concern was that we > don't want to trigger resource-intensive healthchecks on unauthenticated > calls to an API. In the original discussions the plan was to have > healthchecks running in the background, and then the API call would just > return the latest results of the async checks. A small modification to > that was made in this discussion. Instead of having explicit async > processes to gather this data, it will be collected on regular > authenticated API calls. In this way, regularly used functionality will > be healthchecked more frequently, whereas less used areas of the service > will not. In addition, only authenticated users will be able to trigger > potentially resource intensive healthchecks. > > Each project will be responsible for implementing these checks. Since > each project has a different architecture only they can say what > constitutes "healthy" for their service. It's possible we could provide > some common code for things like messaging and database that are used in > many services, but it's likely that many projects will also need some > custom checks. > > I think that covers the major outcomes of this discussion, but we have > no notes from this session so if I forgot something let me know. ;-) > """ > > 0: http://blog.nemebean.com/content/oslo-virtual-ptg-victoria > > On 11/23/20 3:28 AM, Lajos Katona wrote: > > Hi Erno, > > Thanks for the details, we will consider these. > > > > Regards > > Lajos > > > > Erno Kuvaja > ezt írta > > (időpont: 2020. nov. 19., Cs, 18:14): > > > > On Mon, Nov 16, 2020 at 10:21 AM Lajos Katona > > wrote: > > > > Hi, > > > > I send this mail out to summarize the discussion around > > Healthcheck API on Neutron PTG, and start a discussion how we > > can make this most valuable to the operators. > > > > On the Neutron PTG etherpad this topic is from L114: > > https://etherpad.opendev.org/p/neutron-wallaby-ptg . > > > > Background: oslo_middleware provides /healthcheck API path(see > > [1]), which can be used to poll by services like haproxy, and > > gives a plugin mechanism to add some more complicated checks, > > which can be switched on/off from config. > > > > The main questions: > > > > * Some common guidance what to present to the operators (if > > you check [2] and [3] in the comments there are really good > > questions/concerns) > > o Perhaps the API SIG has something about healtcheck, just > > I can't find it. > > * What to present with and without authentication (after > > checking again, I am not sure that it is possible to use > > authentication for the healthcheck) > > o A way forward can be to make it configurable with > > default to authenticated, and give the decision to the > > admin. > > * During the discussion the agreement was to separate the > > frontend health from the backend health and use direct > > indicators (like working db connectivity, and mq > > connectivity) instead of indirect indicators (like agents' > > health). > > > > Thanks in advance for the feedback. > > > > [1] > > > https://docs.openstack.org/oslo.middleware/latest/reference/healthcheck_plugins.html > > [2] https://review.opendev.org/731396 > > [3] https://review.opendev.org/731554 > > > > Regards > > Lajos Katona (lajoskatona) > > > > > > Hi Lajos, > > > > Bit of background in case you don't know. The oslo healthcheck > > middleware is basically a combination of healthcheck middlewares > > carried within the few projects ages ago bloated with the plugin > > framework I don't know of anyone ever adopted using. The main point > > for those middlewares carried by Swift(I think), Glance definitely > > and possibly some other projects before osloing it was to give a > > place for load balancers to ping that does not necessarily need to > > be logged every few seconds nor need to send the excessive amounts > > of auth calls to keystone. If I recall correctly you can already > > place it after keystone middleware if you prefer it being authed, I > > don't know of anyone who does. > > > > Main purpose was to provide a way to detect if the service is not > > responding or by using the disabled by file to bleed the inflight > > connections for maintenance and drop them off the pool for new > > requests. I think the original implementations were somewhere around > > 10-20 lines of code and did just that job pretty reliably. > > > > Based on the plugin model, it's indeed very easy to leak information > > out of that middleware and I think the plugins used need to take > > that into account by careful design. I'd very much prefer not > > breaking the current healthcheck and the very well stabilized API of > > it that has been in use for years just because someone feels like > > it's a good idea to make leaky plugins for it. Realizing that agent > > status might not be the right thing to check is a good start, what > > you really want to have is indication is the API service able to > > take in new requests or not, not if all permutations of those > > requests will succeed on the current system status. Now there are > > ways to chain multiples of these middlewares with different configs > > (with different endpoints) and it might be worth considering having > > your plugins with detailed failure conditions on the admin side that > > is not exposed to the public and just very simple yei/nei on your > > public endpoint. Good luck and I hope you find the correct balance > > of detail from the API and usability. > > > > Best, > > Erno "jokke" Kuvaja > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at est.tech Thu Nov 26 12:39:13 2020 From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer) Date: Thu, 26 Nov 2020 13:39:13 +0100 Subject: [all] CI test result table in the new gerrit review UI Message-ID: Hi, I understand that adapting the old CI test result table to the new gerrit review UI is not a simple task. As a temporary measure I hacked together a tampermonkey user script[1] that does a limited version of the CI table injection from the browser side. I tested it with recent chrome and firefox. Let me know if you have problems with it and I'll try to help. Also feel free to adapt it to your own needs. Cheers, gibi [1] https://gist.github.com/gibizer/717e0cb5b0da0d60d5ecf1e18c0c171a From lucioseki at gmail.com Thu Nov 26 13:00:01 2020 From: lucioseki at gmail.com (Lucio Seki) Date: Thu, 26 Nov 2020 10:00:01 -0300 Subject: [all] CI test result table in the new gerrit review UI In-Reply-To: References: Message-ID: Thanks a lot Balázs! I minified [0] the script and put it in a bookmarklet [1]. It works like a charm [2] :-) Lucio [0] https://javascript-minifier.com/ [1] https://superuser.com/questions/279107/add-a-bookmarklet-in-google-chrome/1341468#1341468 [2] https://imgur.com/a/iy5jPIn On Thu, 26 Nov 2020 at 09:42, Balázs Gibizer wrote: > Hi, > > I understand that adapting the old CI test result table to the new > gerrit review UI is not a simple task. As a temporary measure I hacked > together a tampermonkey user script[1] that does a limited version of > the CI table injection from the browser side. I tested it with recent > chrome and firefox. Let me know if you have problems with it and I'll > try to help. Also feel free to adapt it to your own needs. > > > Cheers, > gibi > > [1] https://gist.github.com/gibizer/717e0cb5b0da0d60d5ecf1e18c0c171a > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssbarnea at redhat.com Thu Nov 26 13:57:03 2020 From: ssbarnea at redhat.com (Sorin Sbarnea) Date: Thu, 26 Nov 2020 05:57:03 -0800 Subject: [all] CI test result table in the new gerrit review UI In-Reply-To: References: Message-ID: Thanks! i works! tMaybe now you can propose a CR to update the old script that no longer worked? https://opendev.org/x/coats/src/branch/master/coats/openstack_gerrit_zuul_status.user.js#bypass=true There is one example where it does not play very nice due to lots of changes sharing the same topic: https://review.opendev.org/c/openstack/ansible-role-collect-logs/+/734217 Probably you can just replace the script, but I would bother to increase the versioning because once we merge it, existing users may be able to detect an update. PS. Add me as reviewer. -- /sorin On 26 Nov 2020 at 13:00:01, Lucio Seki wrote: > Thanks a lot Balázs! > > I minified [0] the script and put it in a bookmarklet [1]. It works like a > charm [2] :-) > > Lucio > > [0] https://javascript-minifier.com/ > [1] > https://superuser.com/questions/279107/add-a-bookmarklet-in-google-chrome/1341468#1341468 > [2] https://imgur.com/a/iy5jPIn > > On Thu, 26 Nov 2020 at 09:42, Balázs Gibizer > wrote: > >> Hi, >> >> I understand that adapting the old CI test result table to the new >> gerrit review UI is not a simple task. As a temporary measure I hacked >> together a tampermonkey user script[1] that does a limited version of >> the CI table injection from the browser side. I tested it with recent >> chrome and firefox. Let me know if you have problems with it and I'll >> try to help. Also feel free to adapt it to your own needs. >> >> >> Cheers, >> gibi >> >> [1] https://gist.github.com/gibizer/717e0cb5b0da0d60d5ecf1e18c0c171a >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at est.tech Thu Nov 26 14:14:31 2020 From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer) Date: Thu, 26 Nov 2020 15:14:31 +0100 Subject: [all] CI test result table in the new gerrit review UI In-Reply-To: References: Message-ID: <78QEKQ.CLUIVGAQECDP3@est.tech> On Thu, Nov 26, 2020 at 05:57, Sorin Sbarnea wrote: > Thanks! i works! > > tMaybe now you can propose a CR to update the old script that no > longer worked? > https://opendev.org/x/coats/src/branch/master/coats/openstack_gerrit_zuul_status.user.js#bypass=true Sorry, I have no intention to do a full update on the original script. As far as I remember the old gerrit CI table did a lot more than what I hacked together and I have not enough time and knowledge to cover that. Also I'm not sure how the above script relates the solution in the old gerrit that was injected server side instead of injected from the client side. > > There is one example where it does not play very nice due to lots of > changes sharing the same topic: > https://review.opendev.org/c/openstack/ansible-role-collect-logs/+/734217 What I see here is that there is a lot of related changes and the table is added at the end of the long list. But overall it works for me on this patch too. What is your specific problem? Cheers, gibi > > Probably you can just replace the script, but I would bother to > increase the versioning because once we merge it, existing users may > be able to detect an update. > > PS. Add me as reviewer. > -- > /sorin > > > On 26 Nov 2020 at 13:00:01, Lucio Seki wrote: >> Thanks a lot Balázs! >> >> I minified [0] the script and put it in a bookmarklet [1]. It works >> like a charm [2] :-) >> >> Lucio >> >> [0] https://javascript-minifier.com/ >> [1] >> https://superuser.com/questions/279107/add-a-bookmarklet-in-google-chrome/1341468#1341468 >> [2] https://imgur.com/a/iy5jPIn >> >> On Thu, 26 Nov 2020 at 09:42, Balázs Gibizer >> wrote: >>> Hi, >>> >>> I understand that adapting the old CI test result table to the new >>> gerrit review UI is not a simple task. As a temporary measure I >>> hacked >>> together a tampermonkey user script[1] that does a limited version >>> of >>> the CI table injection from the browser side. I tested it with >>> recent >>> chrome and firefox. Let me know if you have problems with it and >>> I'll >>> try to help. Also feel free to adapt it to your own needs. >>> >>> >>> Cheers, >>> gibi >>> >>> [1] >>> https://gist.github.com/gibizer/717e0cb5b0da0d60d5ecf1e18c0c171a >>> >>> >>> From mnaser at vexxhost.com Thu Nov 26 14:23:54 2020 From: mnaser at vexxhost.com (Mohammed Naser) Date: Thu, 26 Nov 2020 09:23:54 -0500 Subject: [Freezer][Keystone][Mistral][Monasca][Murano][Openstack-Chef][Openstack-Helm][Openstacksdk][Trove][Watcher][Zun] Action required: Gerrit code audit In-Reply-To: References: Message-ID: Hello there, This email is to confirm that all project teams have effectively completed the audit as per the October 20 Gerrit Outage Update email: http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html, Thank you all for your support, Regards, On Mon, Nov 16, 2020 at 10:45 AM Mohammed Naser wrote: > > Hello there, > > As per the `service-announce` on October 20 regarding Gerrit Outage > Update email http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html, > all project teams are required to audit changes for projects from > 2020-10-01 to 2020-10-21. I'm reaching out to those projects in > particular who the TC believes have not completed their audit yet. > > Let us know if you need any type of assistance in completing the audit. > > In case you didn’t know you needed to do this, feel free to reach out > for support. > > Regards, > Mohammed > > -- > Mohammed Naser > VEXXHOST, Inc. -- Mohammed Naser VEXXHOST, Inc. From fungi at yuggoth.org Thu Nov 26 14:37:07 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 26 Nov 2020 14:37:07 +0000 Subject: [all][infra] CI test result table in the new gerrit review UI In-Reply-To: References: Message-ID: <20201126143706.ejhc5u2qhtzg2qnr@yuggoth.org> On 2020-11-26 05:57:03 -0800 (-0800), Sorin Sbarnea wrote: > Maybe now you can propose a CR to update the old script that no > longer worked? [...] As discussed over months leading up to the upgrade, modern Gerrit gives us the ability to have properly supported WebUI plugins using a real extension API, so that we can stop limping along with hacks to modify the interface internals in unstable and unsupported ways. I really don't want us to be stuck continuing to maintain the old mechanism. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From goel.nitish10 at gmail.com Thu Nov 26 12:11:09 2020 From: goel.nitish10 at gmail.com (Nitish Goel) Date: Thu, 26 Nov 2020 17:41:09 +0530 Subject: XDG_SESSION_TYPE error on devstack installation In-Reply-To: References: Message-ID: Thanks Balázs, This workaround export XDG_SESSION_TYPE='' worked for me. Thanks, Nitish Goel On Wed, Nov 25, 2020 at 10:07 PM Balázs Gibizer wrote: > > > On Wed, Nov 25, 2020 at 09:42, Nitish Goel > wrote: > > Hi Team, > > > > I'm trying to install a devstack on a ubuntu 18.04 VM having python > > 3.6.9 but getting below error. Any suggestions? > > python - 3.6.9 > > stack user with sudo access. > > pip version - pip 20.2.4 from > > /usr/local/lib/python3.6/dist-packages/pip (python 3.6) > > > https://stackoverflow.com/questions/64989221/xdg-session-type-error-on-devstack-installation > > NFO keystone.cmd.bootstrap [None > > req-f46e9c41-1b14-4e5b-82b2-ada81e8b0dcd None None] Created region > > RegionOne > > INFO keystone.cmd.bootstrap [None > > req-f46e9c41-1b14-4e5b-82b2-ada81e8b0dcd None None] Created public > > endpoint http://10.61.62.241/identity > > INFO keystone.cmd.bootstrap [None > > req-f46e9c41-1b14-4e5b-82b2-ada81e8b0dcd None None] Created admin > > endpoint http://10.61.62.241/identity > > > > > > +./stack.sh:main:1084 create_keystone_accounts > > +lib/keystone:create_keystone_accounts:314 local admin_project > > ++lib/keystone:create_keystone_accounts:315 oscwrap project show > > admin -f value -c id > > Traceback (most recent call last): > > File "/usr/local/bin/openstack", line 5, in > > from openstackclient.shell import main > > File > > "/usr/local/lib/python3.6/dist-packages/openstackclient/shell.py", > > line 24, in > > from osc_lib import shell > > File "/usr/local/lib/python3.6/dist-packages/osc_lib/shell.py", > > line 24, in > > from cliff import app > > File "/usr/local/lib/python3.6/dist-packages/cliff/app.py", line > > 24, in > > import cmd2 > > File "/usr/local/lib/python3.6/dist-packages/cmd2/__init__.py", > > line 30, in > > from .cmd2 import Cmd > > File "/usr/local/lib/python3.6/dist-packages/cmd2/cmd2.py", line > > 48, in > > from .clipboard import can_clip, get_paste_buffer, > > write_to_paste_buffer > > File "/usr/local/lib/python3.6/dist-packages/cmd2/clipboard.py", > > line 12, in > > _ = pyperclip.paste() > > File > > "/usr/local/lib/python3.6/dist-packages/pyperclip/__init__.py", line > > 680, in lazy_load_stub_paste > > copy, paste = determine_clipboard() > > File > > "/usr/local/lib/python3.6/dist-packages/pyperclip/__init__.py", line > > 568, in determine_clipboard > > os.environ["XDG_SESSION_TYPE"] == "wayland" and > > File "/usr/lib/python3.6/os.py", line 669, in __getitem__ > > raise KeyError(key) from None > > KeyError: 'XDG_SESSION_TYPE' > > > > ++functions-common:oscwrap:2346 return 1 > > +lib/keystone:create_keystone_accounts:315 admin_project= > > +lib/keystone:create_keystone_accounts:1 exit_trap > > +./stack.sh:exit_trap:491 local r=1 > > ++./stack.sh:exit_trap:492 jobs -p > > +./stack.sh:exit_trap:492 jobs= > > +./stack.sh:exit_trap:495 [[ -n '' ]] > > +./stack.sh:exit_trap:501 '[' -f /tmp/tmp.LRWsRkTTkV > > ']' > > +./stack.sh:exit_trap:502 rm /tmp/tmp.LRWsRkTTkV > > +./stack.sh:exit_trap:506 kill_spinner > > +./stack.sh:kill_spinner:401 '[' '!' -z '' ']' > > +./stack.sh:exit_trap:508 [[ 1 -ne 0 ]] > > +./stack.sh:exit_trap:509 echo 'Error on exit' > > Error on exit > > +./stack.sh:exit_trap:511 type -p generate-subunit > > +./stack.sh:exit_trap:512 generate-subunit > > 1606228299 592 fail > > +./stack.sh:exit_trap:514 [[ -z /opt/stack/logs ]] > > +./stack.sh:exit_trap:517 /usr/bin/python3.6 > > /opt/stack/devstack/tools/worlddump.py -d /opt/stack/logs > > +./stack.sh:exit_trap:526 exit 1 > > > I've seen the same error in my Ubuntu 18.04 devstack on master. I > stopped digging when I saw that the code that blows are 15 months > old[1]. As a workaround I did > > $ export XDG_SESSION_TYPE='' > $ ./unstack.sh && ./stack.sh > > And it worked. > > [1] > > https://github.com/asweigart/pyperclip/blame/master/src/pyperclip/__init__.py#L568 > > Cheers, > gibi > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at est.tech Thu Nov 26 15:00:25 2020 From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer) Date: Thu, 26 Nov 2020 16:00:25 +0100 Subject: [all][infra] CI test result table in the new gerrit review UI In-Reply-To: <20201126143706.ejhc5u2qhtzg2qnr@yuggoth.org> References: <20201126143706.ejhc5u2qhtzg2qnr@yuggoth.org> Message-ID: On Thu, Nov 26, 2020 at 14:37, Jeremy Stanley wrote: > On 2020-11-26 05:57:03 -0800 (-0800), Sorin Sbarnea wrote: >> Maybe now you can propose a CR to update the old script that no >> longer worked? > [...] > > As discussed over months leading up to the upgrade, modern Gerrit > gives us the ability to have properly supported WebUI plugins using > a real extension API, so that we can stop limping along with hacks > to modify the interface internals in unstable and unsupported ways. > I really don't want us to be stuck continuing to maintain the old > mechanism. I totally agree. The user script I created is a hack that is hard to maintain. I intended it as a temporary solution until a proper server side solution can be created. Cheers, gibi > -- > Jeremy Stanley From smooney at redhat.com Thu Nov 26 15:01:34 2020 From: smooney at redhat.com (Sean Mooney) Date: Thu, 26 Nov 2020 15:01:34 +0000 Subject: [all][infra] CI test result table in the new gerrit review UI In-Reply-To: <20201126143706.ejhc5u2qhtzg2qnr@yuggoth.org> References: <20201126143706.ejhc5u2qhtzg2qnr@yuggoth.org> Message-ID: <70b4978a4281a175306a0f3e26ca591bd00d41f1.camel@redhat.com> On Thu, 2020-11-26 at 14:37 +0000, Jeremy Stanley wrote: > On 2020-11-26 05:57:03 -0800 (-0800), Sorin Sbarnea wrote: > > Maybe now you can propose a CR to update the old script that no > > longer worked? > [...] > > As discussed over months leading up to the upgrade, modern Gerrit > gives us the ability to have properly supported WebUI plugins using > a real extension API, so that we can stop limping along with hacks > to modify the interface internals in unstable and unsupported ways. > I really don't want us to be stuck continuing to maintain the old > mechanism. ya doing this as a suppoably ui plugin is ultimately the way to go the current script provide by gibi is a nice stop gap for those that miss it From mnaser at vexxhost.com Thu Nov 26 15:08:06 2020 From: mnaser at vexxhost.com (Mohammed Naser) Date: Thu, 26 Nov 2020 10:08:06 -0500 Subject: [tc] weekly update & agenda In-Reply-To: References: Message-ID: On Wed, Nov 25, 2020 at 9:06 AM Mohammed Naser wrote: > > 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. > > # Patches > ## Open Reviews > - Clarify the requirements for supports-api-interoperability > https://review.opendev.org/c/openstack/governance/+/760562 > - Add election schedule exceptions in charter > https://review.opendev.org/c/openstack/governance/+/751941 > - Add Resolution of TC stance on the OpenStackClient > https://review.opendev.org/c/openstack/governance/+/759904 > - Add assert:supports-standalone > https://review.opendev.org/c/openstack/governance/+/722399 > - Remove assert_supports-zero-downtime-upgrade tag > https://review.opendev.org/c/openstack/governance/+/761975 > - Add Magpie charm to OpenStack charms > https://review.opendev.org/c/openstack/governance/+/762820 > - Propose Kendall Nelson for vice chair > https://review.opendev.org/c/openstack/governance/+/762014 > - Clarify impact on releases for SIGs > https://review.opendev.org/c/openstack/governance/+/752699 > > ## General Changes > - Move Placement under Nova's governance > https://review.opendev.org/c/openstack/governance/+/760917 > > ## Other Reminders > - Our next [TC] Weekly meeting is scheduled for November 26. If you > would like to add topics for discussion, please go to > https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting > and fill out your suggestions by Wednesday, November 26th, at 0000 > UTC. It's Thanksgiving in the US and I seem to have missed that as a Canadian. :) Given that no one has showed up in that case, we are skipping this meeting. > Thanks for reading! > Mohammed & Kendall > > -- > Mohammed Naser > VEXXHOST, Inc. -- Mohammed Naser VEXXHOST, Inc. From tdecacqu at redhat.com Thu Nov 26 15:10:09 2020 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Thu, 26 Nov 2020 15:10:09 +0000 Subject: [all][infra] CI test result table in the new gerrit review UI In-Reply-To: <20201126143706.ejhc5u2qhtzg2qnr@yuggoth.org> References: <20201126143706.ejhc5u2qhtzg2qnr@yuggoth.org> Message-ID: <87tutctar2.tristanC@fedora> On Thu, Nov 26, 2020 at 14:37 Jeremy Stanley wrote: > On 2020-11-26 05:57:03 -0800 (-0800), Sorin Sbarnea wrote: >> Maybe now you can propose a CR to update the old script that no >> longer worked? > [...] > > As discussed over months leading up to the upgrade, modern Gerrit > gives us the ability to have properly supported WebUI plugins using > a real extension API, so that we can stop limping along with hacks > to modify the interface internals in unstable and unsupported ways. > I really don't want us to be stuck continuing to maintain the old > mechanism. > -- > Jeremy Stanley Here is a CR to add the test result table back in the new gerrit UI: https://review.opendev.org/c/opendev/system-config/+/763891 This new implementation uses the javascript plugin extension API. Regards, -Tristan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 515 bytes Desc: not available URL: From fungi at yuggoth.org Thu Nov 26 15:19:06 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 26 Nov 2020 15:19:06 +0000 Subject: [all][infra] CI test result table in the new gerrit review UI In-Reply-To: <87tutctar2.tristanC@fedora> References: <20201126143706.ejhc5u2qhtzg2qnr@yuggoth.org> <87tutctar2.tristanC@fedora> Message-ID: <20201126151906.2573xhh35dhblmnh@yuggoth.org> On 2020-11-26 15:10:09 +0000 (+0000), Tristan Cacqueray wrote: [...] > Here is a CR to add the test result table back in the new gerrit UI: > > https://review.opendev.org/c/opendev/system-config/+/763891 > > This new implementation uses the javascript plugin extension API. Thanks--that was quick work! -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From smooney at redhat.com Thu Nov 26 15:59:02 2020 From: smooney at redhat.com (Sean Mooney) Date: Thu, 26 Nov 2020 15:59:02 +0000 Subject: [all][infra] CI test result table in the new gerrit review UI In-Reply-To: <20201126151906.2573xhh35dhblmnh@yuggoth.org> References: <20201126143706.ejhc5u2qhtzg2qnr@yuggoth.org> <87tutctar2.tristanC@fedora> <20201126151906.2573xhh35dhblmnh@yuggoth.org> Message-ID: <716a66de7a2cb45ded010d01f6c344ba74dbd7de.camel@redhat.com> On Thu, 2020-11-26 at 15:19 +0000, Jeremy Stanley wrote: > On 2020-11-26 15:10:09 +0000 (+0000), Tristan Cacqueray wrote: > [...] > > Here is a CR to add the test result table back in the new gerrit UI: > > > >   https://review.opendev.org/c/opendev/system-config/+/763891 > > > > This new implementation uses the javascript plugin extension API. > > Thanks--that was quick work! is that going to be moved to the zuul org in opendev as a part of the zuul projects deliverables. i kind of think it makes sne to develop it there rather then on the rdo gerrit instance. looking at the impleation it does not look like this owrks teh ssame way by parsing the comment https://softwarefactory-project.io/cgit/software-factory/zuul-results-gerrit-plugin/tree/src/ZuulResultsPlugin.re#n115 will this just show the results form zuul. it need to pars all the comments form the third party cis too. basicaly you need to parse all coment form a author that end isn CI and comments form zuul From mrxlazuardin at gmail.com Thu Nov 26 16:08:57 2020 From: mrxlazuardin at gmail.com (Lazuardi Nasution) Date: Thu, 26 Nov 2020 23:08:57 +0700 Subject: SFC for OVN Message-ID: Hi, By https://docs.openstack.org/neutron/ussuri/admin/config-sfc.html, it is stated that SFC essentially is the SDN version of PBR. On the other side, PBR is supported by OVN. Is there any initiative of Neutron SFC driver for OVN which utilize native PBR support of OVN without having to alternate the OVN itself? For example, for having a port pair of port A to port B for flow classifier of HTTP traffic, we might make PBR which match HTTP traffic from port A address and set the next hop to port B address. The other way which might be used is destination NATing (redirection) on port A for HTTP traffic to port B address. OVN has native support for NAT too, but I think the PBR way is better. Best regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrxlazuardin at gmail.com Thu Nov 26 16:32:56 2020 From: mrxlazuardin at gmail.com (Lazuardi Nasution) Date: Thu, 26 Nov 2020 23:32:56 +0700 Subject: SFC for OVN In-Reply-To: References: Message-ID: Hi, Nutanix approach might be interesting. http://www.openvswitch.org/support/ovscon2018/6/1530-manohar.pdf Best regards, On Thu, Nov 26, 2020 at 11:08 PM Lazuardi Nasution wrote: > Hi, > > By https://docs.openstack.org/neutron/ussuri/admin/config-sfc.html, it is > stated that SFC essentially is the SDN version of PBR. On the other side, > PBR is supported by OVN. Is there any initiative of Neutron SFC driver for > OVN which utilize native PBR support of OVN without having to alternate the > OVN itself? > > For example, for having a port pair of port A to port B for flow > classifier of HTTP traffic, we might make PBR which match HTTP traffic from > port A address and set the next hop to port B address. The other way which > might be used is destination NATing (redirection) on port A for HTTP > traffic to port B address. OVN has native support for NAT too, but I think > the PBR way is better. > > Best regards, > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtantsur at redhat.com Thu Nov 26 16:54:53 2020 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Thu, 26 Nov 2020 17:54:53 +0100 Subject: [ironic] [tripleo] RFC: lzma vs gzip for compressing IPA initramfs Message-ID: Hi folks, I've been playing with ways to reduce the size of our IPA images. While package removals can only save us tens of megabytes, switching from gzip to lzma reduces the size by around a third (from 373M to 217M in my testing). What's the caveat? The unpacking time increases VERY substantially. On my nested virt lab the 217M image took around 5 minutes to unpack. I'm not sure how much it will impact real bare metal, please feel free to test https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/764371 and tell me. So, what do you think? Switching to lzma by default will likely affect CI run time (assuming we still have DIB jobs somewhere...) and development environments, but it will also provide a visible reduction in the image size (which benefit all environments). Large TripleO images may particularly benefit from this (but also particularly affected by the unpacking time). Feedback is very welcome. Dmitry -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill -------------- next part -------------- An HTML attachment was scrubbed... URL: From tdecacqu at redhat.com Thu Nov 26 17:30:12 2020 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Thu, 26 Nov 2020 17:30:12 +0000 Subject: [all][infra] CI test result table in the new gerrit review UI In-Reply-To: <716a66de7a2cb45ded010d01f6c344ba74dbd7de.camel@redhat.com> References: <20201126143706.ejhc5u2qhtzg2qnr@yuggoth.org> <87tutctar2.tristanC@fedora> <20201126151906.2573xhh35dhblmnh@yuggoth.org> <716a66de7a2cb45ded010d01f6c344ba74dbd7de.camel@redhat.com> Message-ID: <87r1ogt49n.tristanC@fedora> On Thu, Nov 26, 2020 at 15:59 Sean Mooney wrote: > On Thu, 2020-11-26 at 15:19 +0000, Jeremy Stanley wrote: >> On 2020-11-26 15:10:09 +0000 (+0000), Tristan Cacqueray wrote: >> [...] >> > Here is a CR to add the test result table back in the new gerrit UI: >> > >> >   https://review.opendev.org/c/opendev/system-config/+/763891 >> > >> > This new implementation uses the javascript plugin extension API. >> >> Thanks--that was quick work! You're welcome :) > is that going to be moved to the zuul org in opendev as a part of the zuul projects > deliverables. > > i kind of think it makes sne to develop it there rather then on the rdo gerrit instance. > I'd be happy to move the project to the opendev gerrit. > looking at the impleation it does not look like this owrks teh ssame way by parsing the comment > https://softwarefactory-project.io/cgit/software-factory/zuul-results-gerrit-plugin/tree/src/ZuulResultsPlugin.re#n115 > That is correct, this is using the Gerrit Js plugin api, which let you register a `showChange` callback, which is called with the change info https://gerrit-review.googlesource.com/Documentation/rest-api-changes.html#change-info Thus no need to hack through the dom to get the comments. Note that the gerrit related code is in another project here: https://softwarefactory-project.io/cgit/software-factory/re-gerrit/ > will this just show the results form zuul. it need to pars all the comments form the third party cis too. > basicaly you need to parse all coment form a author that end isn CI and comments form zuul It should do that already, though I haven't tested it with real data. I guess the next step would be to enable such plugin on review-dev. Cheers, -Tristan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 515 bytes Desc: not available URL: From fungi at yuggoth.org Thu Nov 26 17:45:17 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 26 Nov 2020 17:45:17 +0000 Subject: [all][infra] CI test result table in the new gerrit review UI In-Reply-To: <87r1ogt49n.tristanC@fedora> References: <20201126143706.ejhc5u2qhtzg2qnr@yuggoth.org> <87tutctar2.tristanC@fedora> <20201126151906.2573xhh35dhblmnh@yuggoth.org> <716a66de7a2cb45ded010d01f6c344ba74dbd7de.camel@redhat.com> <87r1ogt49n.tristanC@fedora> Message-ID: <20201126174517.akyuykwmlwc2z6ei@yuggoth.org> On 2020-11-26 17:30:12 +0000 (+0000), Tristan Cacqueray wrote: [...] > It should do that already, though I haven't tested it with real > data. I guess the next step would be to enable such plugin on > review-dev. Well, review-dev hasn't been kept consistent with production and we were planning to decommission it entirely in the coming days along with the temporary review-test we used to run through various upgrade scenarios to get timing data. Probably the easiest solution will be for one of OpenDev's Zuul admins to arrange an autohold for a build which includes your new plugin, and then we can demo it there before releasing it again (three cheers for "testing like production!"). -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From smooney at redhat.com Thu Nov 26 18:02:21 2020 From: smooney at redhat.com (Sean Mooney) Date: Thu, 26 Nov 2020 18:02:21 +0000 Subject: [all][infra] CI test result table in the new gerrit review UI In-Reply-To: <87r1ogt49n.tristanC@fedora> References: <20201126143706.ejhc5u2qhtzg2qnr@yuggoth.org> <87tutctar2.tristanC@fedora> <20201126151906.2573xhh35dhblmnh@yuggoth.org> <716a66de7a2cb45ded010d01f6c344ba74dbd7de.camel@redhat.com> <87r1ogt49n.tristanC@fedora> Message-ID: On Thu, 2020-11-26 at 17:30 +0000, Tristan Cacqueray wrote: > On Thu, Nov 26, 2020 at 15:59 Sean Mooney wrote: > > On Thu, 2020-11-26 at 15:19 +0000, Jeremy Stanley wrote: > > > On 2020-11-26 15:10:09 +0000 (+0000), Tristan Cacqueray wrote: > > > [...] > > > > Here is a CR to add the test result table back in the new gerrit UI: > > > > > > > >   https://review.opendev.org/c/opendev/system-config/+/763891 > > > > > > > > This new implementation uses the javascript plugin extension API. > > > > > > Thanks--that was quick work! > > You're welcome :) > > > is that going to be moved to the zuul org in opendev as a part of the zuul projects > > deliverables. > > > > i kind of think it makes sne to develop it there rather then on the rdo gerrit instance. > > > > I'd be happy to move the project to the opendev gerrit. > > > looking at the impleation it does not look like this owrks teh ssame way by parsing the comment > > https://softwarefactory-project.io/cgit/software-factory/zuul-results-gerrit-plugin/tree/src/ZuulResultsPlugin.re#n115 > > > > That is correct, this is using the Gerrit Js plugin api, which let you > register a `showChange` callback, which is called with the change info > https://gerrit-review.googlesource.com/Documentation/rest-api-changes.html#change-info > > Thus no need to hack through the dom to get the comments. > > Note that the gerrit related code is in another project here: >   https://softwarefactory-project.io/cgit/software-factory/re-gerrit/ > > > will this just show the results form zuul. it need to pars all the comments form the third party cis too. > > basicaly you need to parse all coment form a author that end isn CI and comments form zuul > > It should do that already, though I haven't tested it with real data. I > guess the next step would be to enable such plugin on review-dev. so the author regular expression is only looking for zuul https://softwarefactory-project.io/cgit/software-factory/re-gerrit/tree/src/CI.re#n41 so it lookes liek you would need to refactor that slightly to match comments form autors that end in ci too. each CI systems comemtn then need have there won tabel section with the job results for that ci to mimic the same behavior we had in the old ui. > > Cheers, > -Tristan From tdecacqu at redhat.com Thu Nov 26 18:10:34 2020 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Thu, 26 Nov 2020 18:10:34 +0000 Subject: [all][infra] CI test result table in the new gerrit review UI In-Reply-To: <20201126174517.akyuykwmlwc2z6ei@yuggoth.org> References: <20201126143706.ejhc5u2qhtzg2qnr@yuggoth.org> <87tutctar2.tristanC@fedora> <20201126151906.2573xhh35dhblmnh@yuggoth.org> <716a66de7a2cb45ded010d01f6c344ba74dbd7de.camel@redhat.com> <87r1ogt49n.tristanC@fedora> <20201126174517.akyuykwmlwc2z6ei@yuggoth.org> Message-ID: <87o8jkt2ed.tristanC@fedora> On Thu, Nov 26, 2020 at 17:45 Jeremy Stanley wrote: > On 2020-11-26 17:30:12 +0000 (+0000), Tristan Cacqueray wrote: > [...] >> It should do that already, though I haven't tested it with real >> data. I guess the next step would be to enable such plugin on >> review-dev. > > Well, review-dev hasn't been kept consistent with production and we > were planning to decommission it entirely in the coming days along > with the temporary review-test we used to run through various > upgrade scenarios to get timing data. > > Probably the easiest solution will be for one of OpenDev's Zuul > admins to arrange an autohold for a build which includes your new > plugin, and then we can demo it there before releasing it again > (three cheers for "testing like production!"). > -- > Jeremy Stanley Well there are some unit tests too here: https://softwarefactory-project.io/cgit/software-factory/re-gerrit/tree/tests/Spec.re And I made sure the table looks similar to the previous implementation. It's quite a simple plugin and I don't expect it to be able to cause problem. Though I'd be happy to get a test instance and feed it with real ci comments to demonstrate the results. -Tristan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 515 bytes Desc: not available URL: From moguimar at redhat.com Thu Nov 26 19:30:35 2020 From: moguimar at redhat.com (Moises Guimaraes de Medeiros) Date: Thu, 26 Nov 2020 20:30:35 +0100 Subject: [oslo] py-amqp TLS peer authentication Message-ID: Hi all, This email is about a potential MITM attack, I would like to get some input on my proposed solution. *Disclaimer: I'm not an oslo.messaging expert or even versed in its codebase but I have a good* * number of hours working with TLS already.* Back in September, there was a fix[1] in py-amqp to stop to use deprecated method ssl.wrap_socket. Although I didn't follow anything about oslo.messaging, the PR was brought to my attention by Hervé, another oslo core, who sees me as an SME on TLS among the oslo cores. I didn't follow the entire conversation back then, I was only able to give some quick input, but Hervé was able to finish the PR with the help of another developer. Then earlier this month, another PR[2] was reintroducing a couple of parameters that got dropped in the deprecation fix. At that point it was raised the possibility of a MITM attack in an issue[3] and by reintroducing the dropped parameters, the problem should be fixed. A couple of days went by and I started to have a hunch that there could still be more to fix. I went to py-amqp codebase instead of just looking to the diffs on GitHub and noticed a not straightforward logic on how verify_mode and check_hostname were being set. Today I had time to go back to the py-amqp codebase and rework the _wrap_socket_sni() method. I've put up this PR[4] and it is already failing in my travis[5] for integration tests which make me believe that the client sockets were actually not validating the server certs. There are a few more comments on the fix in the description of PR[4]. [1]: https://github.com/celery/py-amqp/pull/327 [2]: https://github.com/celery/py-amqp/pull/344 [3]: https://github.com/celery/py-amqp/issues/342 [4]: https://github.com/celery/py-amqp/pull/347 [5]: https://travis-ci.com/github/moisesguimaraes/py-amqp/builds/204747399 Thanks, -- Moisés Guimarães Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Thu Nov 26 19:34:49 2020 From: hberaud at redhat.com (Herve Beraud) Date: Thu, 26 Nov 2020 20:34:49 +0100 Subject: [ptl][release][stable][EM] Extended Maintenance - Stein In-Reply-To: <9445d2df-4dd2-1b2e-de50-84db3bd141bd@est.tech> References: <9445d2df-4dd2-1b2e-de50-84db3bd141bd@est.tech> Message-ID: Hello, Stein's transition to extended maintenance is now fully completed! https://releases.openstack.org/ Thanks to everyone who helped on it! Le lun. 2 nov. 2020 à 16:39, Előd Illés a écrit : > Hi, > > Reminder: the planned date for Stein transition to Extended Maintenance > is next Wednesday. If you have planned to do a final release, then it is > a good time to do now. > > Warning: Do not merge and release risky patches in a hurry! Remember > that Stein will be open for further patches, the only thing is that > there won't be further official, upstream release anymore. > > Thanks, > > Előd > > > On 2020. 10. 15. 10:55, Előd Illés wrote: > > Hi, > > > > As Victoria was released yesterday and we are in a less busy period, it > > is a good opportunity to call your attention to the following: > > > > In less than a month Stein is planned to enter into Extended > > Maintenance phase [1] (planned date: 2020-11-11). > > > > I have generated the list of *open* and *unreleased* changes in > > *stable/stein* for the follows-policy tagged repositories [2]. These > > lists could help the teams, who are planning to do a *final* release on > > Stein before moving stable/stein branches to Extended Maintenance. Feel > > free to edit and extend these lists to track your progress! > > > > * At the transition date the Release Team will tag the *latest* (Stein) > > releases of repositories with *stein-em* tag. > > * After the transition stable/stein will be still open for bugfixes, > > but there won't be any official releases. > > > > NOTE: teams, please focus on wrapping up your libraries first if there > > is any concern about the changes, in order to avoid broken releases! > > > > Thanks, > > > > Előd > > > > [1] https://releases.openstack.org > > [2] https://etherpad.openstack.org/p/stein-final-release-before-em > > > > > > > > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Thu Nov 26 21:56:54 2020 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 26 Nov 2020 16:56:54 -0500 Subject: OVS-DPDK poor performance with Intel 82599 Message-ID: Folks, I am playing with DPDK on my openstack with NIC model 82599 and seeing poor performance, i may be wrong with my numbers so want to see what the community thinks about these results. Compute node hardware: CPU: Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz Memory: 64G NIC: Intel 82599 (dual 10G port) [root at compute-lxb-3 ~]# ovs-vswitchd --version ovs-vswitchd (Open vSwitch) 2.13.2 DPDK 19.11.3 VM dpdk (DUT): 8vCPU / 8GB memory I have configured my computer node for all best practice available on the internet to get more performance out. 1. Used isolcpus to islocate CPUs 2. 4 dedicated core for PMD 3. echo isolated_cores=1,9,25,33 >> /etc/tuned/cpu-partitioning-variables.conf 4. Huge pages 5. CPU pinning for VM 6. increase ( ovs-vsctl set interface dpdk-1 options:n_rxq=4 ) 7. VM virtio_ring = 1024 After doing all above I am getting the following result using the Trex packet generator using 64B UDP stream (Total-PPS : 391.93 Kpps) Do you think it's an acceptable result or should it be higher on these NIC models? On the internet folks say it should be a million packets per second so not sure what and how those people reached there or i am missing something in my load test profile. Notes: I am using 8vCPU core on VM do you think adding more cores will help? OR should i add more PMD? Cpu Utilization : 2.2 % 1.8 Gb/core Platform_factor : 1.0 Total-Tx : 200.67 Mbps Total-Rx : 200.67 Mbps Total-PPS : 391.93 Kpps Total-CPS : 391.89 Kcps Expected-PPS : 700.00 Kpps Expected-CPS : 700.00 Kcps Expected-BPS : 358.40 Mbps This is my all configuration: grub.conf: GRUB_CMDLINE_LINUX="vmalloc=384M crashkernel=auto rd.lvm.lv=rootvg01/lv01 console=ttyS1,118200 rhgb quiet intel_iommu=on iommu=pt spectre_v2=off nopti pti=off nospec_store_bypass_disable spec_store_bypass_disable=off l1tf=off default_hugepagesz=1GB hugepagesz=1G hugepages=60 transparent_hugepage=never selinux=0 isolcpus=2,3,4,5,6,7,10,11,12,13,14,15,26,27,28,29,30,31,34,35,36,37,38,39" [root at compute-lxb-3 ~]# ovs-appctl dpif/show netdev at ovs-netdev: hit:605860720 missed:2129 br-int: br-int 65534/3: (tap) int-br-vlan 1/none: (patch: peer=phy-br-vlan) patch-tun 2/none: (patch: peer=patch-int) vhu1d64ea7d-d9 5/6: (dpdkvhostuserclient: configured_rx_queues=8, configured_tx_queues=8, mtu=1500, requested_rx_queues=8, requested_tx_queues=8) vhu9c32faf6-ac 6/7: (dpdkvhostuserclient: configured_rx_queues=8, configured_tx_queues=8, mtu=1500, requested_rx_queues=8, requested_tx_queues=8) br-tun: br-tun 65534/4: (tap) patch-int 1/none: (patch: peer=patch-tun) vxlan-0a410071 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=10.65.0.114, remote_ip=10.65.0.113) br-vlan: br-vlan 65534/1: (tap) dpdk-1 2/2: (dpdk: configured_rx_queues=4, configured_rxq_descriptors=2048, configured_tx_queues=5, configured_txq_descriptors=2048, lsc_interrupt_mode=false, mtu=1500, requested_rx_queues=4, requested_rxq_descriptors=2048, requested_tx_queues=5, requested_txq_descriptors=2048, rx_csum_offload=true, tx_tso_offload=false) phy-br-vlan 1/none: (patch: peer=int-br-vlan) [root at compute-lxb-3 ~]# ovs-appctl dpif-netdev/pmd-rxq-show pmd thread numa_id 0 core_id 1: isolated : false port: dpdk-1 queue-id: 0 (enabled) pmd usage: 0 % port: vhu1d64ea7d-d9 queue-id: 3 (enabled) pmd usage: 0 % port: vhu1d64ea7d-d9 queue-id: 4 (enabled) pmd usage: 0 % port: vhu9c32faf6-ac queue-id: 3 (enabled) pmd usage: 0 % port: vhu9c32faf6-ac queue-id: 4 (enabled) pmd usage: 0 % pmd thread numa_id 0 core_id 9: isolated : false port: dpdk-1 queue-id: 1 (enabled) pmd usage: 0 % port: vhu1d64ea7d-d9 queue-id: 2 (enabled) pmd usage: 0 % port: vhu1d64ea7d-d9 queue-id: 5 (enabled) pmd usage: 0 % port: vhu9c32faf6-ac queue-id: 2 (enabled) pmd usage: 0 % port: vhu9c32faf6-ac queue-id: 5 (enabled) pmd usage: 0 % pmd thread numa_id 0 core_id 25: isolated : false port: dpdk-1 queue-id: 3 (enabled) pmd usage: 0 % port: vhu1d64ea7d-d9 queue-id: 0 (enabled) pmd usage: 0 % port: vhu1d64ea7d-d9 queue-id: 7 (enabled) pmd usage: 0 % port: vhu9c32faf6-ac queue-id: 0 (enabled) pmd usage: 0 % port: vhu9c32faf6-ac queue-id: 7 (enabled) pmd usage: 0 % pmd thread numa_id 0 core_id 33: isolated : false port: dpdk-1 queue-id: 2 (enabled) pmd usage: 0 % port: vhu1d64ea7d-d9 queue-id: 1 (enabled) pmd usage: 0 % port: vhu1d64ea7d-d9 queue-id: 6 (enabled) pmd usage: 0 % port: vhu9c32faf6-ac queue-id: 1 (enabled) pmd usage: 0 % port: vhu9c32faf6-ac queue-id: 6 (enabled) pmd usage: 0 % From skaplons at redhat.com Thu Nov 26 22:08:55 2020 From: skaplons at redhat.com (Slawek Kaplonski) Date: Thu, 26 Nov 2020 23:08:55 +0100 Subject: [neutron] Drivers meeting - 27.11.2020 Message-ID: <20201126220855.mvgvg7ooqqgw3txq@p1.localdomain> Hi, As it's Thanksgiving week and Black Friday so our US folks will probably not be there and lets cancel the meeting this week. But we have couple of new RFEs which needs to be triaged: * https://bugs.launchpad.net/neutron/+bug/1905391 * https://bugs.launchpad.net/neutron/+bug/1905295 * https://bugs.launchpad.net/neutron/+bug/1905115 * https://bugs.launchpad.net/neutron/+bug/1900934 So please take some time and help with triaging them so we will be able to discuss them next week hopefully :) Have a great weekend! -- Slawek Kaplonski Principal Software Engineer Red Hat From smooney at redhat.com Fri Nov 27 01:11:17 2020 From: smooney at redhat.com (Sean Mooney) Date: Fri, 27 Nov 2020 01:11:17 +0000 Subject: OVS-DPDK poor performance with Intel 82599 In-Reply-To: References: Message-ID: <05cc630458f1a7b62e14c7627f8784d38c7e5911.camel@redhat.com> On Thu, 2020-11-26 at 16:56 -0500, Satish Patel wrote: > Folks, > > I am playing with DPDK on my openstack with NIC model 82599 and seeing > poor performance, i may be wrong with my numbers so want to see what > the community thinks about these results. > > Compute node hardware: > > CPU: Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz > Memory: 64G > NIC: Intel 82599 (dual 10G port) > > [root at compute-lxb-3 ~]# ovs-vswitchd --version > ovs-vswitchd (Open vSwitch) 2.13.2 > DPDK 19.11.3 > > VM dpdk (DUT): > 8vCPU / 8GB memory > > I have configured my computer node for all best practice available on > the internet to get more performance out. > > 1. Used isolcpus to islocate CPUs > 2. 4 dedicated core for PMD > 3. echo isolated_cores=1,9,25,33 >> /etc/tuned/cpu-partitioning-variables.conf > 4. Huge pages > 5. CPU pinning for VM > 6. increase ( ovs-vsctl set interface dpdk-1 options:n_rxq=4 ) > 7. VM virtio_ring = 1024 > > After doing all above I am getting the following result using the Trex > packet generator using 64B UDP stream (Total-PPS : 391.93 > Kpps) Do you think it's an acceptable result or should it be higher > on these NIC models? that is one of inteles oldest generation 10G nics that is supported by dpdk but it shoudl still get to about 11 million packet per second with 1-2 cores my guess would be that the vm or trafic gerneator are not sentding and reciving mac learnign frames like arp properly and as a result the packtes are flooding which will severly reduce perfomance. > > On the internet folks say it should be a million packets per second so > not sure what and how those people reached there or i am missing > something in my load test profile. even kernel ovs will break a million packets persecond so 400Kpps is far to low there is sometin gmisconfigred but im not sure what specificly form what you have shared. as i said my best guess would be that the backets are flooding because the vm is not responding to arp and the normal action is not learn the mac address. you could rule that out by adding hardcoded rules but you could also check the flow tables to confirm > > Notes: I am using 8vCPU core on VM do you think adding more cores will > help? OR should i add more PMD? > > Cpu Utilization : 2.2 % 1.8 Gb/core >  Platform_factor : 1.0 >  Total-Tx : 200.67 Mbps >  Total-Rx : 200.67 Mbps >  Total-PPS : 391.93 Kpps >  Total-CPS : 391.89 Kcps > >  Expected-PPS : 700.00 Kpps >  Expected-CPS : 700.00 Kcps >  Expected-BPS : 358.40 Mbps > > > This is my all configuration: > > grub.conf: > GRUB_CMDLINE_LINUX="vmalloc=384M crashkernel=auto > rd.lvm.lv=rootvg01/lv01 console=ttyS1,118200 rhgb quiet intel_iommu=on > iommu=pt spectre_v2=off nopti pti=off nospec_store_bypass_disable > spec_store_bypass_disable=off l1tf=off default_hugepagesz=1GB > hugepagesz=1G hugepages=60 transparent_hugepage=never selinux=0 > isolcpus=2,3,4,5,6,7,10,11,12,13,14,15,26,27,28,29,30,31,34,35,36,37,38,39" > > > [root at compute-lxb-3 ~]# ovs-appctl dpif/show > netdev at ovs-netdev: hit:605860720 missed:2129 >   br-int: >     br-int 65534/3: (tap) >     int-br-vlan 1/none: (patch: peer=phy-br-vlan) >     patch-tun 2/none: (patch: peer=patch-int) >     vhu1d64ea7d-d9 5/6: (dpdkvhostuserclient: configured_rx_queues=8, > configured_tx_queues=8, mtu=1500, requested_rx_queues=8, > requested_tx_queues=8) >     vhu9c32faf6-ac 6/7: (dpdkvhostuserclient: configured_rx_queues=8, > configured_tx_queues=8, mtu=1500, requested_rx_queues=8, > requested_tx_queues=8) >   br-tun: >     br-tun 65534/4: (tap) >     patch-int 1/none: (patch: peer=patch-tun) >     vxlan-0a410071 2/5: (vxlan: egress_pkt_mark=0, key=flow, > local_ip=10.65.0.114, remote_ip=10.65.0.113) >   br-vlan: >     br-vlan 65534/1: (tap) >     dpdk-1 2/2: (dpdk: configured_rx_queues=4, > configured_rxq_descriptors=2048, configured_tx_queues=5, > configured_txq_descriptors=2048, lsc_interrupt_mode=false, mtu=1500, > requested_rx_queues=4, requested_rxq_descriptors=2048, > requested_tx_queues=5, requested_txq_descriptors=2048, > rx_csum_offload=true, tx_tso_offload=false) >     phy-br-vlan 1/none: (patch: peer=int-br-vlan) > > > [root at compute-lxb-3 ~]# ovs-appctl dpif-netdev/pmd-rxq-show > pmd thread numa_id 0 core_id 1: >   isolated : false >   port: dpdk-1 queue-id: 0 (enabled) pmd usage: 0 % >   port: vhu1d64ea7d-d9 queue-id: 3 (enabled) pmd usage: 0 % >   port: vhu1d64ea7d-d9 queue-id: 4 (enabled) pmd usage: 0 % >   port: vhu9c32faf6-ac queue-id: 3 (enabled) pmd usage: 0 % >   port: vhu9c32faf6-ac queue-id: 4 (enabled) pmd usage: 0 % > pmd thread numa_id 0 core_id 9: >   isolated : false >   port: dpdk-1 queue-id: 1 (enabled) pmd usage: 0 % >   port: vhu1d64ea7d-d9 queue-id: 2 (enabled) pmd usage: 0 % >   port: vhu1d64ea7d-d9 queue-id: 5 (enabled) pmd usage: 0 % >   port: vhu9c32faf6-ac queue-id: 2 (enabled) pmd usage: 0 % >   port: vhu9c32faf6-ac queue-id: 5 (enabled) pmd usage: 0 % > pmd thread numa_id 0 core_id 25: >   isolated : false >   port: dpdk-1 queue-id: 3 (enabled) pmd usage: 0 % >   port: vhu1d64ea7d-d9 queue-id: 0 (enabled) pmd usage: 0 % >   port: vhu1d64ea7d-d9 queue-id: 7 (enabled) pmd usage: 0 % >   port: vhu9c32faf6-ac queue-id: 0 (enabled) pmd usage: 0 % >   port: vhu9c32faf6-ac queue-id: 7 (enabled) pmd usage: 0 % > pmd thread numa_id 0 core_id 33: >   isolated : false >   port: dpdk-1 queue-id: 2 (enabled) pmd usage: 0 % >   port: vhu1d64ea7d-d9 queue-id: 1 (enabled) pmd usage: 0 % >   port: vhu1d64ea7d-d9 queue-id: 6 (enabled) pmd usage: 0 % >   port: vhu9c32faf6-ac queue-id: 1 (enabled) pmd usage: 0 % >   port: vhu9c32faf6-ac queue-id: 6 (enabled) pmd usage: 0 % > From satish.txt at gmail.com Fri Nov 27 03:10:20 2020 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 26 Nov 2020 22:10:20 -0500 Subject: OVS-DPDK poor performance with Intel 82599 In-Reply-To: <05cc630458f1a7b62e14c7627f8784d38c7e5911.camel@redhat.com> References: <05cc630458f1a7b62e14c7627f8784d38c7e5911.camel@redhat.com> Message-ID: Sean, Let me say "Happy Thanksgiving to you and your family". Thank you for taking time and reply, the last 2 days I was trying to find you on IRC to discuss this issue. Let me explain to you what I did so far. * First i did load-testing on my bare metal compute node to see how far my Trex can go and i found it Hit 2 million packet per second (Not sure if this is good result or not but it prove that i can hit at least 1 million pps) * Then i create sriov VM on that compute node with ( 8vCPU/8GB mem) and i re-run Trex and my max result was 323kpps without dropping packet) I found Intel 82599 nic VF only support 2 queue rx/tx and that could be bottleneck) * Finally i decided to build DPDK vm on it and see how Trex behaved on it and i found it hit max ~400kpps with 4 PMD core. (little better than sriov because now i have 4 rx/tx queue thanks to 4 PMD core) For Trex load-test i did statically assigned ARP entries because its part of Trex process to use static arp. You are saying it should hit 11 million pps but question is what tools you guys using to hit that number i didn't see anyone using Trex for DPDK testing most of people using testpmd. what kind of vm and (vCPU/memory people using to reach 11 million pps?) I am stick to 8 vcpu because majority of my server has 8 core VM size so trying to get most of performance out of it.) If you have your load-test scenario available or tools available then please share some information so i will try to mimic that in my environment. thank you for reply. ~S On Thu, Nov 26, 2020 at 8:14 PM Sean Mooney wrote: > > On Thu, 2020-11-26 at 16:56 -0500, Satish Patel wrote: > > Folks, > > > > I am playing with DPDK on my openstack with NIC model 82599 and seeing > > poor performance, i may be wrong with my numbers so want to see what > > the community thinks about these results. > > > > Compute node hardware: > > > > CPU: Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz > > Memory: 64G > > NIC: Intel 82599 (dual 10G port) > > > > [root at compute-lxb-3 ~]# ovs-vswitchd --version > > ovs-vswitchd (Open vSwitch) 2.13.2 > > DPDK 19.11.3 > > > > VM dpdk (DUT): > > 8vCPU / 8GB memory > > > > I have configured my computer node for all best practice available on > > the internet to get more performance out. > > > > 1. Used isolcpus to islocate CPUs > > 2. 4 dedicated core for PMD > > 3. echo isolated_cores=1,9,25,33 >> /etc/tuned/cpu-partitioning-variables.conf > > 4. Huge pages > > 5. CPU pinning for VM > > 6. increase ( ovs-vsctl set interface dpdk-1 options:n_rxq=4 ) > > 7. VM virtio_ring = 1024 > > > > After doing all above I am getting the following result using the Trex > > packet generator using 64B UDP stream (Total-PPS : 391.93 > > Kpps) Do you think it's an acceptable result or should it be higher > > on these NIC models? > that is one of inteles oldest generation 10G nics that is supported by dpdk > > but it shoudl still get to about 11 million packet per second with 1-2 cores > > my guess would be that the vm or trafic gerneator are not sentding and reciving mac learnign > frames like arp properly and as a result the packtes are flooding which will severly > reduce perfomance. > > > > On the internet folks say it should be a million packets per second so > > not sure what and how those people reached there or i am missing > > something in my load test profile. > > even kernel ovs will break a million packets persecond so 400Kpps is far to low > there is sometin gmisconfigred but im not sure what specificly form what you have shared. > as i said my best guess would be that the backets are flooding because the vm is not > responding to arp and the normal action is not learn the mac address. > > you could rule that out by adding hardcoded rules but you could also check the flow tables to confirm > > > > Notes: I am using 8vCPU core on VM do you think adding more cores will > > help? OR should i add more PMD? > > > > Cpu Utilization : 2.2 % 1.8 Gb/core > > Platform_factor : 1.0 > > Total-Tx : 200.67 Mbps > > Total-Rx : 200.67 Mbps > > Total-PPS : 391.93 Kpps > > Total-CPS : 391.89 Kcps > > > > Expected-PPS : 700.00 Kpps > > Expected-CPS : 700.00 Kcps > > Expected-BPS : 358.40 Mbps > > > > > > This is my all configuration: > > > > grub.conf: > > GRUB_CMDLINE_LINUX="vmalloc=384M crashkernel=auto > > rd.lvm.lv=rootvg01/lv01 console=ttyS1,118200 rhgb quiet intel_iommu=on > > iommu=pt spectre_v2=off nopti pti=off nospec_store_bypass_disable > > spec_store_bypass_disable=off l1tf=off default_hugepagesz=1GB > > hugepagesz=1G hugepages=60 transparent_hugepage=never selinux=0 > > isolcpus=2,3,4,5,6,7,10,11,12,13,14,15,26,27,28,29,30,31,34,35,36,37,38,39" > > > > > > [root at compute-lxb-3 ~]# ovs-appctl dpif/show > > netdev at ovs-netdev: hit:605860720 missed:2129 > > br-int: > > br-int 65534/3: (tap) > > int-br-vlan 1/none: (patch: peer=phy-br-vlan) > > patch-tun 2/none: (patch: peer=patch-int) > > vhu1d64ea7d-d9 5/6: (dpdkvhostuserclient: configured_rx_queues=8, > > configured_tx_queues=8, mtu=1500, requested_rx_queues=8, > > requested_tx_queues=8) > > vhu9c32faf6-ac 6/7: (dpdkvhostuserclient: configured_rx_queues=8, > > configured_tx_queues=8, mtu=1500, requested_rx_queues=8, > > requested_tx_queues=8) > > br-tun: > > br-tun 65534/4: (tap) > > patch-int 1/none: (patch: peer=patch-tun) > > vxlan-0a410071 2/5: (vxlan: egress_pkt_mark=0, key=flow, > > local_ip=10.65.0.114, remote_ip=10.65.0.113) > > br-vlan: > > br-vlan 65534/1: (tap) > > dpdk-1 2/2: (dpdk: configured_rx_queues=4, > > configured_rxq_descriptors=2048, configured_tx_queues=5, > > configured_txq_descriptors=2048, lsc_interrupt_mode=false, mtu=1500, > > requested_rx_queues=4, requested_rxq_descriptors=2048, > > requested_tx_queues=5, requested_txq_descriptors=2048, > > rx_csum_offload=true, tx_tso_offload=false) > > phy-br-vlan 1/none: (patch: peer=int-br-vlan) > > > > > > [root at compute-lxb-3 ~]# ovs-appctl dpif-netdev/pmd-rxq-show > > pmd thread numa_id 0 core_id 1: > > isolated : false > > port: dpdk-1 queue-id: 0 (enabled) pmd usage: 0 % > > port: vhu1d64ea7d-d9 queue-id: 3 (enabled) pmd usage: 0 % > > port: vhu1d64ea7d-d9 queue-id: 4 (enabled) pmd usage: 0 % > > port: vhu9c32faf6-ac queue-id: 3 (enabled) pmd usage: 0 % > > port: vhu9c32faf6-ac queue-id: 4 (enabled) pmd usage: 0 % > > pmd thread numa_id 0 core_id 9: > > isolated : false > > port: dpdk-1 queue-id: 1 (enabled) pmd usage: 0 % > > port: vhu1d64ea7d-d9 queue-id: 2 (enabled) pmd usage: 0 % > > port: vhu1d64ea7d-d9 queue-id: 5 (enabled) pmd usage: 0 % > > port: vhu9c32faf6-ac queue-id: 2 (enabled) pmd usage: 0 % > > port: vhu9c32faf6-ac queue-id: 5 (enabled) pmd usage: 0 % > > pmd thread numa_id 0 core_id 25: > > isolated : false > > port: dpdk-1 queue-id: 3 (enabled) pmd usage: 0 % > > port: vhu1d64ea7d-d9 queue-id: 0 (enabled) pmd usage: 0 % > > port: vhu1d64ea7d-d9 queue-id: 7 (enabled) pmd usage: 0 % > > port: vhu9c32faf6-ac queue-id: 0 (enabled) pmd usage: 0 % > > port: vhu9c32faf6-ac queue-id: 7 (enabled) pmd usage: 0 % > > pmd thread numa_id 0 core_id 33: > > isolated : false > > port: dpdk-1 queue-id: 2 (enabled) pmd usage: 0 % > > port: vhu1d64ea7d-d9 queue-id: 1 (enabled) pmd usage: 0 % > > port: vhu1d64ea7d-d9 queue-id: 6 (enabled) pmd usage: 0 % > > port: vhu9c32faf6-ac queue-id: 1 (enabled) pmd usage: 0 % > > port: vhu9c32faf6-ac queue-id: 6 (enabled) pmd usage: 0 % > > > > > From iwienand at redhat.com Fri Nov 27 03:20:04 2020 From: iwienand at redhat.com (Ian Wienand) Date: Fri, 27 Nov 2020 14:20:04 +1100 Subject: [all][infra] CI test result table in the new gerrit review UI In-Reply-To: <87o8jkt2ed.tristanC@fedora> References: <20201126143706.ejhc5u2qhtzg2qnr@yuggoth.org> <87tutctar2.tristanC@fedora> <20201126151906.2573xhh35dhblmnh@yuggoth.org> <716a66de7a2cb45ded010d01f6c344ba74dbd7de.camel@redhat.com> <87r1ogt49n.tristanC@fedora> <20201126174517.akyuykwmlwc2z6ei@yuggoth.org> <87o8jkt2ed.tristanC@fedora> Message-ID: <20201127032004.GC522326@fedora19.localdomain> On Thu, Nov 26, 2020 at 06:10:34PM +0000, Tristan Cacqueray wrote: > > Probably the easiest solution will be for one of OpenDev's Zuul > > admins to arrange an autohold for a build which includes your new > > plugin, and then we can demo it there before releasing it again > > (three cheers for "testing like production!"). > Though I'd be happy to get a test instance and feed it with real ci > comments to demonstrate the results. We probably want to document this. As a start, I put a hold on a job. After I set /etc/hosts for review.opendev.org to the held node locally, I could log into the test gerrit (otherwise i'm redirected to the real site). I then created a openstack/diskimage-builder project via the UI, just for testing. I started getting some errors which [2] resolved after a container restart. I copied in the raw git tree from the real openstack/diskimage-builder git repo, and ran a re-index by sshing in as the 'Gerrit Code Review' user using suexec ssh -i ~gerrit2/review_site/etc/ssh_host_rsa_key -p 29418 -l 'Gerrit Code Review' localhost 'suexec --as "Ian Wienand" gerrit index changes-in-project openstack/diskimage-builder' I don't know if that's right, but it seemed to work. Fiddling with this was where I found [2] Then I could see the dib changes; e.g. https://104.130.172.52/c/openstack/diskimage-builder/+/751610 Very willing to take suggestions on what we could do better here. It would probably be awesome if we could figure out automated import of a live tree in the system-config test, so we have a bunch of changes with zuul comments pre-populated. Perhaps something like keep a zip of a smaller repo that has a bunch of reviews and comments, and populate that into the testing gerrit? I can see the plugin is installed, because in the web console you get the log from [3,4]. However, I can't actually see the table. Tristan -- have sent you a note separately on how to log in for live debugging if you like. I can't say too much, because Tristan has written something and I haven't, but the choice of Reason or BuckleScript or OCaml or whatever is going on [5] really lowers the "bus factor" of this. I can read it and get the gist of what's going on; but it compiles down to [6] which I have no idea how to debug. AFAICT, Reason 3.0.4 was released 3 years ago, so it's either finished or ... not that active. I use emacs and write email in mutt -- I'm the first to admit I'm behind on the latest web framework trends. But after investigating TBH I remain unconvinced mostly that we can mantain this indefinitely, and secondly that the tooling will remain maintained. Anyway, getting a better flow for testing plugins will serve us all well at any rate. -i [1] https://review.opendev.org/c/opendev/system-config/+/764396 gerrit: fix db/ mount for gate testing [2] https://review.opendev.org/c/opendev/system-config/+/764395 gerrit: set ownership on ~gerrit2/.ssh directory [3] https://softwarefactory-project.io/cgit/software-factory/re-gerrit/tree/src/Plugin.re#n23 [4] https://softwarefactory-project.io/cgit/software-factory/zuul-results-gerrit-plugin/tree/src/ZuulResultsPlugin.re#n112 [5] https://reasonml.github.io/ [6] https://104.130.172.52/plugins/zuul-results/static/zuul-results.js [7] https://github.com/facebook/reason/releases/tag/3.0.4 From iwienand at redhat.com Fri Nov 27 05:39:21 2020 From: iwienand at redhat.com (Ian Wienand) Date: Fri, 27 Nov 2020 16:39:21 +1100 Subject: [all][infra] CI test result table in the new gerrit review UI In-Reply-To: <20201127032004.GC522326@fedora19.localdomain> References: <20201126143706.ejhc5u2qhtzg2qnr@yuggoth.org> <87tutctar2.tristanC@fedora> <20201126151906.2573xhh35dhblmnh@yuggoth.org> <716a66de7a2cb45ded010d01f6c344ba74dbd7de.camel@redhat.com> <87r1ogt49n.tristanC@fedora> <20201126174517.akyuykwmlwc2z6ei@yuggoth.org> <87o8jkt2ed.tristanC@fedora> <20201127032004.GC522326@fedora19.localdomain> Message-ID: <20201127053921.GD522326@fedora19.localdomain> On Fri, Nov 27, 2020 at 02:20:04PM +1100, Ian Wienand wrote: > I can see the plugin is installed, because in the web console you get > the log from [3,4]. However, I can't actually see the table. I've since realised this is looking for "Zuul" comments, and because All-Users isn't populated with the Zuul user, all the comments on the imported changes come up with "Name of user not set". I don't want to copy the production All-Users into a CI instance. I think we have a bit of a way to go with the automated setup of the gerrit instance in CI. The first thing is getting an admin user that can be used to create projects and other users in an automated, way, etc. That has something to do with initalising with DEVELOPMENT_BECOME_ANY_ACCOUNT ... but I get a bit lost after that ... -i From gmann at ghanshyammann.com Fri Nov 27 06:59:07 2020 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 27 Nov 2020 00:59:07 -0600 Subject: [all][tc][goals] Migrate RBAC Policy Format from JSON to YAML: Week R-20 Update Message-ID: <176087f93b9.df44c4ee755280.5849437234907357270@ghanshyammann.com> Hello Everyone, As you all know, 'Migrate RBAC Policy Format from JSON to YAML' is one of the community-wide goals for Wallaby development cycle. I am starting this thread to report the progress of this work. Tracking: https://etherpad.opendev.org/p/migrate-policy-format-from-json-to-yaml Gerrit Topic: https://review.opendev.org/q/topic:%22policy-json-to-yaml%22+(status:open%20OR%20status:merged) Updates: ======== * Common code of upgrade checks and policy.json file fallback logic is moved from nova to oslo.upgradechecks (in version 1.2.0) and oslo.policy(in version 3.6.0) respectively. ** For upgrade checks, you just need to enable it from the project side. Example: https://review.opendev.org/c/openstack/keystone/+/764240/4/keystone/cmd/status.py ** For olso.policy fallback logic, you just need to bump the min version to 3.6.0. For project who already change the policy_file default in previous releases (like Cinder ) then you can disable this fallback logic via flag 'fallback_to_json_file' * I have started few projects to propose the changes and will continue to do that for other projects too. If you are interested to help, please write it in tracking etherpad [1]. * I am updating the goal documents also for oslo side common code and the latest example. - https://review.opendev.org/c/openstack/governance/+/764261 - This is an example you can refer: https://review.opendev.org/c/openstack/keystone/+/764240 [1] https://etherpad.opendev.org/p/migrate-policy-format-from-json-to-yaml -gmann From hberaud at redhat.com Fri Nov 27 07:53:56 2020 From: hberaud at redhat.com (Herve Beraud) Date: Fri, 27 Nov 2020 08:53:56 +0100 Subject: [release] Release countdown for week R-20, Nov 23 - Nov 27 Message-ID: Greetings Everyone! Development Focus ----------------- The Wallaby-1 milestone is next week, on December 03! Project team plans for the Wallaby cycle should now be solidified. General Information ------------------- If you planned to change the release model for any of your deliverables this cycle, please remember to do so ASAP, before milestone-1. Libraries need to be released at least once per milestone period. Next week, the release team will propose releases for any library which had changes but has not been otherwise released since the Victoria release. PTL's or release liaisons, please watch for these and give a +1 to acknowledge them. If there is some reason to hold off on a release, let us know that as well, by posting a -1. If we do not hear anything at all by the end of the week, we will assume things are OK to proceed. NB: If one of your libraries is still releasing 0.x versions, start thinking about when it will be appropriate to do a 1.0 version. The version number does signal the state, real or perceived, of the library, so we strongly encourage going to a full major version once things are in a good and usable state. Upcoming Deadlines & Dates -------------------------- Wallaby-1 milestone: December 03 Hervé Beraud (hberaud) and the Release Management Team -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From arxcruz at redhat.com Fri Nov 27 08:09:42 2020 From: arxcruz at redhat.com (Arx Cruz) Date: Fri, 27 Nov 2020 09:09:42 +0100 Subject: [tripleo] Please avoid merge patches for releases before Victoria In-Reply-To: References: Message-ID: Hello, Both patches were merged! We are in a better shape now! Happy thanksgiving to everyone! Kind regards, Arx Cruz On Wed, Nov 25, 2020 at 10:30 AM Arx Cruz wrote: > Hello, > > We need these patches [1] landed first in order to merge other patches, > otherwise CI will not be able to properly test it. > > We have already had two known issues [2] related to this problem, so I ask > you for patience while we are merging those patches. > > [1] > https://review.opendev.org/c/openstack/tripleo-quickstart/+/763747 > https://review.opendev.org/#/c/763712 > > [2] > https://launchpad.net/bugs/1903033 > https://bugs.launchpad.net/tripleo/+bug/1905536 > > Kind regards, > > -- > > Arx Cruz > > Software Engineer > > Red Hat EMEA > > arxcruz at redhat.com > @RedHat Red Hat > Red Hat > > > -- Arx Cruz Software Engineer Red Hat EMEA arxcruz at redhat.com @RedHat Red Hat Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdobreli at redhat.com Fri Nov 27 12:19:22 2020 From: bdobreli at redhat.com (Bogdan Dobrelya) Date: Fri, 27 Nov 2020 13:19:22 +0100 Subject: [tripleo] Copying tripleo container images to quay.io Message-ID: So I explored how exactly skopeo copy works with the WIP zstd:chunked compression format. The main case here is when copying *new* layers of the *same* image. What is not the case in TripleO CI. We build images from scratch and tag it only once, like current-tripleo. Here ends that build's lifecycle. Had we decided to change that to update existing images, we could come back and try that new feature of skopeo, or may be even consume it directly via buildah bud, when it's there. Another caveat is that only OCI compliant registries could accept such zstd:chunked compressed layers. But anyway that was a good try... Bogdan Dobrelya bdobreli at redhat.com writes: > Note that skopeo will shortly have the layers diffs [0] based "copy" > operations [1],[2],[3]. It also deduplicates things and uses local cache > to not repeat redundant data transfers. Would be great if TripleO > container registry could start using that super cool feature as early > adoption. > > We could make a build with these patches and try that for the subject > tooling for TCIB distribution over quay.io. > > IIUC, the process is like: > > * as input we have full layers from the source registry, built with TCIB; > * skopeo uses its super powers to redo it on fly into layers diff > * either skopeo as well, or maybe even tripleoclient prepare image CLI > pushes those optimized layers of the images to the target quay.io registry. > * ??? > * profit! > > [0] https://github.com/containers/image/pull/902 > [1] https://github.com/containers/image/pull/1084 > [2] https://github.com/containers/storage/pull/775 > [3] https://github.com/containers/skopeo/pull/1111 -- Best regards, Bogdan Dobrelya, Irc #bogdando From sgolovat at redhat.com Fri Nov 27 13:00:10 2020 From: sgolovat at redhat.com (Sergii Golovatiuk) Date: Fri, 27 Nov 2020 14:00:10 +0100 Subject: [ironic] [tripleo] RFC: lzma vs gzip for compressing IPA initramfs In-Reply-To: References: Message-ID: Hi, LZMA causes very high CPU and memory usage for creating images, leaving less resources for other processes. If Ironic is running alongside with other services that may cause significant impact for them. I would leave gzip option as default, would introduce --lzma as well as --gzip and use lzma on 5-10% of our CI resources to test how it goes. Then after a significant amount of testing we could turn it on as default. Proper deprecation should be applied here as well IMHO. чт, 26 нояб. 2020 г. в 17:57, Dmitry Tantsur : > Hi folks, > > I've been playing with ways to reduce the size of our IPA images. While > package removals can only save us tens of megabytes, switching from gzip to > lzma reduces the size by around a third (from 373M to 217M in my testing). > > What's the caveat? The unpacking time increases VERY substantially. On my > nested virt lab the 217M image took around 5 minutes to unpack. I'm not > sure how much it will impact real bare metal, please feel free to test > https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/764371 > and tell me. > > So, what do you think? Switching to lzma by default will likely affect CI > run time (assuming we still have DIB jobs somewhere...) and development > environments, but it will also provide a visible reduction in the image > size (which benefit all environments). Large TripleO images may > particularly benefit from this (but also particularly affected by the > unpacking time). > > Feedback is very welcome. > > Dmitry > > -- > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael > O'Neill > -- Sergii Golovatiuk Senior Software Developer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtantsur at redhat.com Fri Nov 27 13:14:54 2020 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Fri, 27 Nov 2020 14:14:54 +0100 Subject: [ironic] [tripleo] RFC: lzma vs gzip for compressing IPA initramfs In-Reply-To: References: Message-ID: Hi, On Fri, Nov 27, 2020 at 2:00 PM Sergii Golovatiuk wrote: > Hi, > > LZMA causes very high CPU and memory usage for creating images, leaving > less resources for other processes. If Ironic is running alongside with > other services that may cause significant impact for them. I would leave > gzip option as default, would introduce --lzma as well as --gzip and use > lzma on 5-10% of our CI resources to test how it goes. Then after a > significant amount of testing we could turn it on as default. Proper > deprecation should be applied here as well IMHO. > LZMA packing won't happen on ironic nodes. The images are pre-built and only unpacked on the target machines. Or does TripleO build images every time? Dmitry > > чт, 26 нояб. 2020 г. в 17:57, Dmitry Tantsur : > >> Hi folks, >> >> I've been playing with ways to reduce the size of our IPA images. While >> package removals can only save us tens of megabytes, switching from gzip to >> lzma reduces the size by around a third (from 373M to 217M in my testing). >> >> What's the caveat? The unpacking time increases VERY substantially. On my >> nested virt lab the 217M image took around 5 minutes to unpack. I'm not >> sure how much it will impact real bare metal, please feel free to test >> https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/764371 >> and tell me. >> >> So, what do you think? Switching to lzma by default will likely affect CI >> run time (assuming we still have DIB jobs somewhere...) and development >> environments, but it will also provide a visible reduction in the image >> size (which benefit all environments). Large TripleO images may >> particularly benefit from this (but also particularly affected by the >> unpacking time). >> >> Feedback is very welcome. >> >> Dmitry >> >> -- >> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, >> Commercial register: Amtsgericht Muenchen, HRB 153243, >> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael >> O'Neill >> > > > -- > Sergii Golovatiuk > > Senior Software Developer > > Red Hat > > -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill -------------- next part -------------- An HTML attachment was scrubbed... URL: From ts-takahashi at nec.com Fri Nov 27 13:15:51 2020 From: ts-takahashi at nec.com (=?iso-2022-jp?B?VEFLQUhBU0hJIFRPU0hJQUtJKBskQjliNjYhIUlSTEAbKEIp?=) Date: Fri, 27 Nov 2020 13:15:51 +0000 Subject: [tc][heat][tacker] Discusssion about heat-translater and tosca-parser maintenance Message-ID: Hi, I'm a tacker team member. I'd like to discuss how to maintain heat-translator[1] and tosca-parser[2] repositories. These 2 repositories have not been updated so actively, but tacker often requires code updates for these repositories. Recently, patch merge progress of tacker and these repo do not sometimes match, which affects the development of tacker. For example, our some functional tests on zuul fail because these master codes are not updated. Therefore, tacker members would like to take part more in these 2 developments. Tacker members have already started code reviews, patch posts, etc. If possible, we want some Tacker members to join the core team in the near future. How about this? [1] https://opendev.org/openstack/heat-translator [2] https://opendev.org/openstack/tosca-parser Regards, Toshiaki From smooney at redhat.com Fri Nov 27 13:49:01 2020 From: smooney at redhat.com (Sean Mooney) Date: Fri, 27 Nov 2020 13:49:01 +0000 Subject: OVS-DPDK poor performance with Intel 82599 In-Reply-To: References: <05cc630458f1a7b62e14c7627f8784d38c7e5911.camel@redhat.com> Message-ID: <3ab5f1bd48722c65994dc97ec884ca858934921e.camel@redhat.com> On Thu, 2020-11-26 at 22:10 -0500, Satish Patel wrote: > Sean, > > Let me say "Happy Thanksgiving to you and your family". Thank you for > taking time and reply, the last 2 days I was trying to find you on IRC > to discuss this issue. Let me explain to you what I did so far. > > * First i did load-testing on my bare metal compute node to see how > far my Trex can go and i found it Hit 2 million packet per second (Not > sure if this is good result or not but it prove that i can hit at > least 1 million pps) for 64byte packets on that nic it should be hittihng about 11mpps on one core. that said i have not validated that in a year or two but it could eaisly saturate 10G linerate with 64b packest with 1 cores in the past. > > * Then i create sriov VM on that compute node with ( 8vCPU/8GB mem) > and i re-run Trex and my max result was 323kpps without dropping > packet) I found Intel 82599 nic VF only support 2 queue rx/tx and > that could be bottleneck) a VF can fully saturate the nic and hit 14.4 mpps if your cpu clock rate is fstat enough i.e. >3.2-3.5GHz on a 2.5GHz you porably wont hit that with 1 core but you shoudl get >10mpps > > * Finally i decided to build DPDK vm on it and see how Trex behaved on > it and i found it hit max ~400kpps with 4 PMD core. (little better > than sriov because now i have 4 rx/tx queue thanks to 4 PMD core) ya so these number are far to low for a correctly complied and fuctioning trex binary > > For Trex load-test i did statically assigned ARP entries because its > part of Trex process to use static arp.  > that wont work properly. if you do that the ovs bridge will not have its mac learning table populated so it will flood packets. to do dpdk > You are saying it should hit > 11 million pps but question is what tools you guys using to hit that > number i didn't see anyone using Trex for DPDK testing most of people > using testpmd. trex is a trafic generaotr orginally created by cisco i think it often used in combination with testpmd. testpmd was desing to these the pool mode driver as the name implice but its also uses as a replacement for a device/appliction under test to messure the low level performacne in l2/l3 forading modes or basic mac swap mode. > > what kind of vm and (vCPU/memory people using to reach 11 million > pps?) > 2-4 vcpus with 2G or ram. if dpdk is compile propertly and funtionion you dont need a lot of core although you will need to use cpu pinning and hugepages for the vm and within the vm you will also need hugpeages if you are using dpdk there too. > I am stick to 8 vcpu because majority of my server has 8 core VM > size so trying to get most of performance out of it.) > > If you have your load-test scenario available or tools available then > please share some information so i will try to mimic that in my > environment. thank you for reply. i think you need to start with getting trex to actully hit 10G linerate with small packets. as i said you should not need more then about 2 cores to do that and 1-2 G of hugepages. once you have tha tworking you can move on to the rest but you need to ensure proper mac learning happens and arps are sent and replied too before starting the traffic generattor so that floodign does not happen. can you also provide the output of sudo ovs-vsctl list Open_vSwitch . and the output of sudo ovs-vsctl show, sudo ovs-vsctl list bridge, sudo ovs-vsctl list port and sudo ovs-vsctl list interface i just want to confirm that you have properly confiugred ovs-dpdk to use dpdk i dont work with dpdk that offent any more but i generally used testpmd in the guest with an ixia hardware traffic generator to do performance messurments. i have used trex and it can hit line rate so im not sure why you are seeign such low performance. > > ~S > > > On Thu, Nov 26, 2020 at 8:14 PM Sean Mooney wrote: > > > > On Thu, 2020-11-26 at 16:56 -0500, Satish Patel wrote: > > > Folks, > > > > > > I am playing with DPDK on my openstack with NIC model 82599 and seeing > > > poor performance, i may be wrong with my numbers so want to see what > > > the community thinks about these results. > > > > > > Compute node hardware: > > > > > > CPU: Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz > > > Memory: 64G > > > NIC: Intel 82599 (dual 10G port) > > > > > > [root at compute-lxb-3 ~]# ovs-vswitchd --version > > > ovs-vswitchd (Open vSwitch) 2.13.2 > > > DPDK 19.11.3 > > > > > > VM dpdk (DUT): > > > 8vCPU / 8GB memory > > > > > > I have configured my computer node for all best practice available on > > > the internet to get more performance out. > > > > > > 1. Used isolcpus to islocate CPUs > > > 2. 4 dedicated core for PMD > > > 3. echo isolated_cores=1,9,25,33 >> /etc/tuned/cpu-partitioning-variables.conf > > > 4. Huge pages > > > 5. CPU pinning for VM > > > 6. increase ( ovs-vsctl set interface dpdk-1 options:n_rxq=4 ) > > > 7. VM virtio_ring = 1024 > > > > > > After doing all above I am getting the following result using the Trex > > > packet generator using 64B UDP stream (Total-PPS : 391.93 > > > Kpps) Do you think it's an acceptable result or should it be higher > > > on these NIC models? > > that is one of inteles oldest generation 10G nics that is supported by dpdk > > > > but it shoudl still get to about 11 million packet per second with 1-2 cores > > > > my guess would be that the vm or trafic gerneator are not sentding and reciving mac learnign > > frames like arp properly and as a result the packtes are flooding which will severly > > reduce perfomance. > > > > > > On the internet folks say it should be a million packets per second so > > > not sure what and how those people reached there or i am missing > > > something in my load test profile. > > > > even kernel ovs will break a million packets persecond so 400Kpps is far to low > > there is sometin gmisconfigred but im not sure what specificly form what you have shared. > > as i said my best guess would be that the backets are flooding because the vm is not > > responding to arp and the normal action is not learn the mac address. > > > > you could rule that out by adding hardcoded rules but you could also check the flow tables to confirm > > > > > > Notes: I am using 8vCPU core on VM do you think adding more cores will > > > help? OR should i add more PMD? > > > > > > Cpu Utilization : 2.2 % 1.8 Gb/core > > >  Platform_factor : 1.0 > > >  Total-Tx : 200.67 Mbps > > >  Total-Rx : 200.67 Mbps > > >  Total-PPS : 391.93 Kpps > > >  Total-CPS : 391.89 Kcps > > > > > >  Expected-PPS : 700.00 Kpps > > >  Expected-CPS : 700.00 Kcps > > >  Expected-BPS : 358.40 Mbps > > > > > > > > > This is my all configuration: > > > > > > grub.conf: > > > GRUB_CMDLINE_LINUX="vmalloc=384M crashkernel=auto > > > rd.lvm.lv=rootvg01/lv01 console=ttyS1,118200 rhgb quiet intel_iommu=on > > > iommu=pt spectre_v2=off nopti pti=off nospec_store_bypass_disable > > > spec_store_bypass_disable=off l1tf=off default_hugepagesz=1GB > > > hugepagesz=1G hugepages=60 transparent_hugepage=never selinux=0 > > > isolcpus=2,3,4,5,6,7,10,11,12,13,14,15,26,27,28,29,30,31,34,35,36,37,38,39" > > > > > > > > > [root at compute-lxb-3 ~]# ovs-appctl dpif/show > > > netdev at ovs-netdev: hit:605860720 missed:2129 > > >   br-int: > > >     br-int 65534/3: (tap) > > >     int-br-vlan 1/none: (patch: peer=phy-br-vlan) > > >     patch-tun 2/none: (patch: peer=patch-int) > > >     vhu1d64ea7d-d9 5/6: (dpdkvhostuserclient: configured_rx_queues=8, > > > configured_tx_queues=8, mtu=1500, requested_rx_queues=8, > > > requested_tx_queues=8) > > >     vhu9c32faf6-ac 6/7: (dpdkvhostuserclient: configured_rx_queues=8, > > > configured_tx_queues=8, mtu=1500, requested_rx_queues=8, > > > requested_tx_queues=8) > > >   br-tun: > > >     br-tun 65534/4: (tap) > > >     patch-int 1/none: (patch: peer=patch-tun) > > >     vxlan-0a410071 2/5: (vxlan: egress_pkt_mark=0, key=flow, > > > local_ip=10.65.0.114, remote_ip=10.65.0.113) > > >   br-vlan: > > >     br-vlan 65534/1: (tap) > > >     dpdk-1 2/2: (dpdk: configured_rx_queues=4, > > > configured_rxq_descriptors=2048, configured_tx_queues=5, > > > configured_txq_descriptors=2048, lsc_interrupt_mode=false, mtu=1500, > > > requested_rx_queues=4, requested_rxq_descriptors=2048, > > > requested_tx_queues=5, requested_txq_descriptors=2048, > > > rx_csum_offload=true, tx_tso_offload=false) > > >     phy-br-vlan 1/none: (patch: peer=int-br-vlan) > > > > > > > > > [root at compute-lxb-3 ~]# ovs-appctl dpif-netdev/pmd-rxq-show > > > pmd thread numa_id 0 core_id 1: > > >   isolated : false > > >   port: dpdk-1 queue-id: 0 (enabled) pmd usage: 0 % > > >   port: vhu1d64ea7d-d9 queue-id: 3 (enabled) pmd usage: 0 % > > >   port: vhu1d64ea7d-d9 queue-id: 4 (enabled) pmd usage: 0 % > > >   port: vhu9c32faf6-ac queue-id: 3 (enabled) pmd usage: 0 % > > >   port: vhu9c32faf6-ac queue-id: 4 (enabled) pmd usage: 0 % > > > pmd thread numa_id 0 core_id 9: > > >   isolated : false > > >   port: dpdk-1 queue-id: 1 (enabled) pmd usage: 0 % > > >   port: vhu1d64ea7d-d9 queue-id: 2 (enabled) pmd usage: 0 % > > >   port: vhu1d64ea7d-d9 queue-id: 5 (enabled) pmd usage: 0 % > > >   port: vhu9c32faf6-ac queue-id: 2 (enabled) pmd usage: 0 % > > >   port: vhu9c32faf6-ac queue-id: 5 (enabled) pmd usage: 0 % > > > pmd thread numa_id 0 core_id 25: > > >   isolated : false > > >   port: dpdk-1 queue-id: 3 (enabled) pmd usage: 0 % > > >   port: vhu1d64ea7d-d9 queue-id: 0 (enabled) pmd usage: 0 % > > >   port: vhu1d64ea7d-d9 queue-id: 7 (enabled) pmd usage: 0 % > > >   port: vhu9c32faf6-ac queue-id: 0 (enabled) pmd usage: 0 % > > >   port: vhu9c32faf6-ac queue-id: 7 (enabled) pmd usage: 0 % > > > pmd thread numa_id 0 core_id 33: > > >   isolated : false > > >   port: dpdk-1 queue-id: 2 (enabled) pmd usage: 0 % > > >   port: vhu1d64ea7d-d9 queue-id: 1 (enabled) pmd usage: 0 % > > >   port: vhu1d64ea7d-d9 queue-id: 6 (enabled) pmd usage: 0 % > > >   port: vhu9c32faf6-ac queue-id: 1 (enabled) pmd usage: 0 % > > >   port: vhu9c32faf6-ac queue-id: 6 (enabled) pmd usage: 0 % > > > > > > > > > > From oliver.wenz at dhbw-mannheim.de Fri Nov 27 13:57:27 2020 From: oliver.wenz at dhbw-mannheim.de (Oliver Wenz) Date: Fri, 27 Nov 2020 14:57:27 +0100 Subject: [neutron][openstack-ansible] Instances can only connect to provider-net via tenant-net but not directly In-Reply-To: References: Message-ID: <5a5e31a5-10cf-3db7-3728-28e06681131e@dhbw-mannheim.de> > So this looks like issue during sending notification to Nova. You should check > in Nova logs now why it returned You 422 The relevant nova-compute log on the node where I try to start the instance looks like this: Nov 27 13:33:24 bc1blade15 nova-compute[4240]: 2020-11-27 13:33:24.870 4240 INFO nova.compute.claims [req-4125d882-0753-4a0a-844c-5a948681ffa1 920e739127a14018a55fb4422b0885e7 0f14905dab5546e0adec2b56c0f6be88 - default default] [instance: 20a23a18-0d13-4aba-b0be-37e243b21336] Claim successful on node bc1blade15.openstack.local Nov 27 13:33:26 bc1blade15 nova-compute[4240]: 2020-11-27 13:33:26.151 4240 INFO nova.virt.libvirt.driver [req-4125d882-0753-4a0a-844c-5a948681ffa1 920e739127a14018a55fb4422b0885e7 0f14905dab5546e0adec2b56c0f6be88 - default default] [instance: 20a23a18-0d13-4aba-b0be-37e243b21336] Creating image Nov 27 13:33:31 bc1blade15 nova-compute[4240]: 2020-11-27 13:33:31.463 4240 INFO os_vif [req-4125d882-0753-4a0a-844c-5a948681ffa1 920e739127a14018a55fb4422b0885e7 0f14905dab5546e0adec2b56c0f6be88 - default default] Successfully plugged vif VIFBridge(active=False,address=fa:16:3e:57:d5:f4,bridge_name='brq497a58ad-e5',has_traffic_filtering=True,id=c2e13a92-86bc-4c8e-ad74-1cad0a6bcffc,network=Network(497a58ad-e57c-4bf1-a1c7-dad58f4795ec),plugin='linux_bridge',port_profile=,preserve_on_delete=False,vif_name='tapc2e13a92-86') Nov 27 13:33:33 bc1blade15 nova-compute[4240]: 2020-11-27 13:33:33.961 4240 INFO nova.compute.manager [req-633ff74b-b16d-4063-9f54-5ee618ea2bb9 - - - - -] [instance: 20a23a18-0d13-4aba-b0be-37e243b21336] VM Started (Lifecycle Event) Nov 27 13:33:34 bc1blade15 nova-compute[4240]: 2020-11-27 13:33:34.104 4240 INFO nova.compute.manager [req-633ff74b-b16d-4063-9f54-5ee618ea2bb9 - - - - -] [instance: 20a23a18-0d13-4aba-b0be-37e243b21336] VM Paused (Lifecycle Event) Nov 27 13:33:34 bc1blade15 nova-compute[4240]: 2020-11-27 13:33:34.388 4240 INFO nova.compute.manager [req-633ff74b-b16d-4063-9f54-5ee618ea2bb9 - - - - -] [instance: 20a23a18-0d13-4aba-b0be-37e243b21336] During sync_power_state the instance has a pending task (spawning). Again, the corresponding neutron-server log: Nov 27 13:39:02 infra1-neutron-server-container-cbf4b105 neutron-server[87]: 2020-11-27 13:39:02.106 87 WARNING neutron.notifiers.nova [-] Nova event: {'server_uuid': '20a23a18-0d13-4aba-b0be-37e243b21336', 'name': 'network-vif-deleted', 'tag': 'c2e13a92-86bc-4c8e-ad74-1cad0a6bcffc', 'status': 'failed', 'code': 422} returned with failed status I also looked in all the logs of the nova related services on the managament node for the instance id but didn't find it. So the nova-compute log seems to indicate that the instance can connect to the bridge successfully?! From tdecacqu at redhat.com Fri Nov 27 14:11:21 2020 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Fri, 27 Nov 2020 14:11:21 +0000 Subject: [all][infra] CI test result table in the new gerrit review UI In-Reply-To: <20201127032004.GC522326@fedora19.localdomain> References: <20201126143706.ejhc5u2qhtzg2qnr@yuggoth.org> <87tutctar2.tristanC@fedora> <20201126151906.2573xhh35dhblmnh@yuggoth.org> <716a66de7a2cb45ded010d01f6c344ba74dbd7de.camel@redhat.com> <87r1ogt49n.tristanC@fedora> <20201126174517.akyuykwmlwc2z6ei@yuggoth.org> <87o8jkt2ed.tristanC@fedora> <20201127032004.GC522326@fedora19.localdomain> Message-ID: <87lfemubxy.tristanC@fedora> On Fri, Nov 27, 2020 at 14:20 Ian Wienand wrote: > On Thu, Nov 26, 2020 at 06:10:34PM +0000, Tristan Cacqueray wrote: >> > Probably the easiest solution will be for one of OpenDev's Zuul >> > admins to arrange an autohold for a build which includes your new >> > plugin, and then we can demo it there before releasing it again >> > (three cheers for "testing like production!"). > >> Though I'd be happy to get a test instance and feed it with real ci >> comments to demonstrate the results. > > We probably want to document this. As a start, I put a hold on a job. > > After I set /etc/hosts for review.opendev.org to the held node > locally, I could log into the test gerrit (otherwise i'm redirected to > the real site). > > I then created a openstack/diskimage-builder project via the UI, just > for testing. I started getting some errors which [2] resolved after a > container restart. > > I copied in the raw git tree from the real openstack/diskimage-builder > git repo, and ran a re-index by sshing in as the 'Gerrit Code Review' > user using suexec > > ssh -i ~gerrit2/review_site/etc/ssh_host_rsa_key -p 29418 -l 'Gerrit > Code Review' localhost 'suexec --as "Ian Wienand" gerrit index > changes-in-project openstack/diskimage-builder' > > I don't know if that's right, but it seemed to work. Fiddling with > this was where I found [2] > > Then I could see the dib changes; e.g. > > https://104.130.172.52/c/openstack/diskimage-builder/+/751610 > > Very willing to take suggestions on what we could do better here. It > would probably be awesome if we could figure out automated import of a > live tree in the system-config test, so we have a bunch of changes > with zuul comments pre-populated. Perhaps something like keep a zip > of a smaller repo that has a bunch of reviews and comments, and > populate that into the testing gerrit? > > I can see the plugin is installed, because in the web console you get > the log from [3,4]. However, I can't actually see the table. > > Tristan -- have sent you a note separately on how to log in for live > debugging if you like. > Thanks, I have switched the auth to DEVELOPMENT_BECOME_ANY_ACCOUNT and created a fake Zuul CI comment in https://104.130.172.52/c/openstack/diskimage-builder/+/554002 > I can't say too much, because Tristan has written something and I > haven't, but the choice of Reason or BuckleScript or OCaml or whatever > is going on [5] really lowers the "bus factor" of this. I can read it > and get the gist of what's going on; but it compiles down to [6] which > I have no idea how to debug. AFAICT, Reason 3.0.4 was released 3 > years ago, so it's either finished or ... not that active. I use > emacs and write email in mutt -- I'm the first to admit I'm behind on > the latest web framework trends. But after investigating TBH I remain > unconvinced mostly that we can mantain this indefinitely, and secondly > that the tooling will remain maintained. > >From what I understand, we can either use java and the polymer template system, or the javascript api to implement the zuul results table. I used a `compile to js` language named ReasonML because this let me write applications where most of the runtime errors are simply not possible. Moreover, the code can be compiled to other targets such as Erlang or native assembly. The language was created by the author of ReactJS and it is designed for Javascript developper, see the difference here: https://rescript-lang.org/docs/manual/v8.0.0/overview To debug [6], you would use the same tools as for any javascript applications. For example, using a source map so that the debugger can hook into the non-minified source. I'd be happy to use another implementation, I wrote this one rather quickly to restore the zuul-results build table in the new gerrit. Though I think ReasonML is the right tool for this job. Regards, -Tristan > Anyway, getting a better flow for testing plugins will serve us all > well at any rate. > > -i > > > [1] https://review.opendev.org/c/opendev/system-config/+/764396 gerrit: fix db/ mount for gate testing > [2] https://review.opendev.org/c/opendev/system-config/+/764395 gerrit: set ownership on ~gerrit2/.ssh directory > [3] https://softwarefactory-project.io/cgit/software-factory/re-gerrit/tree/src/Plugin.re#n23 > [4] https://softwarefactory-project.io/cgit/software-factory/zuul-results-gerrit-plugin/tree/src/ZuulResultsPlugin.re#n112 > [5] https://reasonml.github.io/ > [6] https://104.130.172.52/plugins/zuul-results/static/zuul-results.js > [7] https://github.com/facebook/reason/releases/tag/3.0.4 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 515 bytes Desc: not available URL: From skaplons at redhat.com Fri Nov 27 14:51:05 2020 From: skaplons at redhat.com (Slawek Kaplonski) Date: Fri, 27 Nov 2020 15:51:05 +0100 Subject: [neutron][openstack-ansible] Instances can only connect to provider-net via tenant-net but not directly In-Reply-To: <5a5e31a5-10cf-3db7-3728-28e06681131e@dhbw-mannheim.de> References: <5a5e31a5-10cf-3db7-3728-28e06681131e@dhbw-mannheim.de> Message-ID: <5096957.ySr116x7Mg@p1> Hi, Dnia piątek, 27 listopada 2020 14:57:27 CET Oliver Wenz pisze: > > So this looks like issue during sending notification to Nova. You should > > check in Nova logs now why it returned You 422 > > The relevant nova-compute log on the node where I try to start the > instance looks like this: > > Nov 27 13:33:24 bc1blade15 nova-compute[4240]: 2020-11-27 13:33:24.870 > 4240 INFO nova.compute.claims [req-4125d882-0753-4a0a-844c-5a948681ffa1 > 920e739127a14018a55fb4422b0885e7 0f14905dab5546e0adec2b56c0f6be88 - > default default] [instance: 20a23a18-0d13-4aba-b0be-37e243b21336] Claim > successful on node bc1blade15.openstack.local > Nov 27 13:33:26 bc1blade15 nova-compute[4240]: 2020-11-27 13:33:26.151 > 4240 INFO nova.virt.libvirt.driver > [req-4125d882-0753-4a0a-844c-5a948681ffa1 > 920e739127a14018a55fb4422b0885e7 0f14905dab5546e0adec2b56c0f6be88 - > default default] [instance: 20a23a18-0d13-4aba-b0be-37e243b21336] > Creating image > Nov 27 13:33:31 bc1blade15 nova-compute[4240]: 2020-11-27 13:33:31.463 > 4240 INFO os_vif [req-4125d882-0753-4a0a-844c-5a948681ffa1 > 920e739127a14018a55fb4422b0885e7 0f14905dab5546e0adec2b56c0f6be88 - > default default] Successfully plugged vif > VIFBridge(active=False,address=fa:16:3e:57:d5:f4,bridge_name='brq497a58ad-e5 > ',has_traffic_filtering=True,id=c2e13a92-86bc-4c8e-ad74-1cad0a6bcffc,network > =Network(497a58ad-e57c-4bf1-a1c7-dad58f4795ec),plugin='linux_bridge',port_pr > ofile=,preserve_on_delete=False,vif_name='tapc2e13a92-86') Nov 27 > 13:33:33 bc1blade15 nova-compute[4240]: 2020-11-27 13:33:33.961 4240 INFO > nova.compute.manager [req-633ff74b-b16d-4063-9f54-5ee618ea2bb9 - - - - -] > [instance: 20a23a18-0d13-4aba-b0be-37e243b21336] VM Started (Lifecycle > Event) > Nov 27 13:33:34 bc1blade15 nova-compute[4240]: 2020-11-27 13:33:34.104 > 4240 INFO nova.compute.manager [req-633ff74b-b16d-4063-9f54-5ee618ea2bb9 > - - - - -] [instance: 20a23a18-0d13-4aba-b0be-37e243b21336] VM Paused > (Lifecycle Event) > Nov 27 13:33:34 bc1blade15 nova-compute[4240]: 2020-11-27 13:33:34.388 > 4240 INFO nova.compute.manager [req-633ff74b-b16d-4063-9f54-5ee618ea2bb9 > - - - - -] [instance: 20a23a18-0d13-4aba-b0be-37e243b21336] During > sync_power_state the instance has a pending task (spawning). > > Again, the corresponding neutron-server log: > > Nov 27 13:39:02 infra1-neutron-server-container-cbf4b105 > neutron-server[87]: 2020-11-27 13:39:02.106 87 WARNING > neutron.notifiers.nova [-] Nova event: {'server_uuid': > '20a23a18-0d13-4aba-b0be-37e243b21336', 'name': 'network-vif-deleted', > 'tag': 'c2e13a92-86bc-4c8e-ad74-1cad0a6bcffc', 'status': 'failed', > 'code': 422} returned with failed status > > I also looked in all the logs of the nova related services on the > managament node for the instance id but didn't find it. > So the nova-compute log seems to indicate that the instance can connect > to the bridge successfully?! Neutron sends this notification to the nova-api so You should check in nova-api logs. Whole workflow for that process of spawning vm is more or less like below: 1. nova-compute asks neutron for port, 2. neutron creates port and binds it with some mechanism driver - so it has vif_type e.g. "ovs" or "linuxbridge" or some other, 3. nova, based on that vif details plugs port to the proper bridge on host and pauses instance until neutron will not do its job, 4. neutron-l2-agent (linuxbrige or ovs) starts provisioning port and reports to neutron-server when it is done, 5. if there is no any provisioning blocks for that port in neutron db (can be also one from the dhcp agent), neutron sends notification to nova-api that port is ready, 6. nova unpauses vm. In Your case it seems that on step 5 nova reports some error and that You should IMO check. -- Slawek Kaplonski Principal Software Engineer Red Hat From bob.haddleton at nokia.com Fri Nov 27 15:09:41 2020 From: bob.haddleton at nokia.com (HADDLETON, Robert W (Bob)) Date: Fri, 27 Nov 2020 09:09:41 -0600 Subject: [tc][heat][tacker][tosca-parser][heat-translator] Discusssion about heat-translater and tosca-parser maintenance In-Reply-To: References: Message-ID: <9aedf122-5ebb-e29a-d977-b58635cabe51@nokia.com> @spzala and I have been maintaining, as best we can, tosca-parser and heat-translator for the past several years, though our day jobs have moved on to other things.  This hasn't been a problem because of the extremely low activity in both projects, mostly updating for releases and handling a bug fix every once in a while.  While there has been a flurry of new activity in the past week, we are unaware of any issues in these repos causing Tacker build failures or blocking any progress. I know I would be more than happy to add to the core team with the goal of eventually handing off maintenance responsibilities, and I'm pretty sure Sahdev will agree. I'll be back in the office next week, for about a week or so, then off the rest of the year.  I'm glad to start discussions now and plan to start making changes in January, if that works. Thanks, Bob On 11/27/2020 7:15 AM, TAKAHASHI TOSHIAKI(高橋 敏明) wrote: > Hi, > > I'm a tacker team member. > I'd like to discuss how to maintain heat-translator[1] and tosca-parser[2] repositories. > > These 2 repositories have not been updated so actively, but tacker often requires code updates for these repositories. > Recently, patch merge progress of tacker and these repo do not sometimes match, which affects the development of tacker. > For example, our some functional tests on zuul fail because these master codes are not updated. > > Therefore, tacker members would like to take part more in these 2 developments. > Tacker members have already started code reviews, patch posts, etc. > If possible, we want some Tacker members to join the core team in the near future. > > How about this? > > [1] https://opendev.org/openstack/heat-translator > [2] https://opendev.org/openstack/tosca-parser > > > Regards, > Toshiaki > > -------------- next part -------------- A non-text attachment was scrubbed... Name: bob_haddleton.vcf Type: text/x-vcard Size: 252 bytes Desc: not available URL: From gmann at ghanshyammann.com Fri Nov 27 15:21:27 2020 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 27 Nov 2020 09:21:27 -0600 Subject: [tc][heat][tacker][tosca-parser][heat-translator] Discusssion about heat-translater and tosca-parser maintenance In-Reply-To: <9aedf122-5ebb-e29a-d977-b58635cabe51@nokia.com> References: <9aedf122-5ebb-e29a-d977-b58635cabe51@nokia.com> Message-ID: <1760a4b795a.10e369974791414.187901784754730298@ghanshyammann.com> ---- On Fri, 27 Nov 2020 09:09:41 -0600 HADDLETON, Robert W (Bob) wrote ---- > @spzala and I have been maintaining, as best we can, tosca-parser and > heat-translator for the past several years, though our day jobs have > moved on to other things. This hasn't been a problem because of the > extremely low activity in both projects, mostly updating for releases > and handling a bug fix every once in a while. While there has been a > flurry of new activity in the past week, we are unaware of any issues in > these repos causing Tacker build failures or blocking any progress. > > I know I would be more than happy to add to the core team with the goal > of eventually handing off maintenance responsibilities, and I'm pretty > sure Sahdev will agree. > > I'll be back in the office next week, for about a week or so, then off > the rest of the year. I'm glad to start discussions now and plan to > start making changes in January, if that works. +1. That is a good idea to have more maintainer from the different team which is done in much other repo too like horizon UI, devstack plugins repo. Both of these repos are under the Heat project and Rico (heat PTL) also can help with this. -gmann > > Thanks, > > Bob > > On 11/27/2020 7:15 AM, TAKAHASHI TOSHIAKI(高橋 敏明) wrote: > > Hi, > > > > I'm a tacker team member. > > I'd like to discuss how to maintain heat-translator[1] and tosca-parser[2] repositories. > > > > These 2 repositories have not been updated so actively, but tacker often requires code updates for these repositories. > > Recently, patch merge progress of tacker and these repo do not sometimes match, which affects the development of tacker. > > For example, our some functional tests on zuul fail because these master codes are not updated. > > > > Therefore, tacker members would like to take part more in these 2 developments. > > Tacker members have already started code reviews, patch posts, etc. > > If possible, we want some Tacker members to join the core team in the near future. > > > > How about this? > > > > [1] https://opendev.org/openstack/heat-translator > > [2] https://opendev.org/openstack/tosca-parser > > > > > > Regards, > > Toshiaki > > > > > > From gmann at ghanshyammann.com Fri Nov 27 16:06:07 2020 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 27 Nov 2020 10:06:07 -0600 Subject: [all][nova][placement] Merging 'placement' IRC channel into 'nova' Message-ID: <1760a746085.12009b632794243.8203831493523526677@ghanshyammann.com> Hello Everyone, As the placement project is under Nova governance now[1], can we merge the IRC channel 'placement' into nova? I think that can be done via redirect way? [1] https://review.opendev.org/c/openstack/governance/+/760917 -gmann From balazs.gibizer at est.tech Fri Nov 27 16:11:24 2020 From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer) Date: Fri, 27 Nov 2020 17:11:24 +0100 Subject: [all][nova][placement] Merging 'placement' IRC channel into 'nova' In-Reply-To: <1760a746085.12009b632794243.8203831493523526677@ghanshyammann.com> References: <1760a746085.12009b632794243.8203831493523526677@ghanshyammann.com> Message-ID: <0BQGKQ.QBCSGB2EXOSN@est.tech> On Fri, Nov 27, 2020 at 10:06, Ghanshyam Mann wrote: > Hello Everyone, > > As the placement project is under Nova governance now[1], can we > merge the IRC channel 'placement' into nova? > I think that can be done via redirect way? Thanks for bringing this up. I as the Nova PTL (and now as Placement PTL) agree to redirect every placement related IRC traffic to the #openstack-nova channel. Cheers, gibi > > [1] https://review.opendev.org/c/openstack/governance/+/760917 > > -gmann > From fungi at yuggoth.org Fri Nov 27 16:23:16 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 27 Nov 2020 16:23:16 +0000 Subject: [all][nova][placement] Merging 'placement' IRC channel into 'nova' In-Reply-To: <1760a746085.12009b632794243.8203831493523526677@ghanshyammann.com> References: <1760a746085.12009b632794243.8203831493523526677@ghanshyammann.com> Message-ID: <20201127162316.k2w52d4j6jsh2zro@yuggoth.org> On 2020-11-27 10:06:07 -0600 (-0600), Ghanshyam Mann wrote: [...] > can we merge the IRC channel 'placement' into nova? I think that > can be done via redirect way? [...] We've got a process documented here: https://docs.opendev.org/opendev/system-config/latest/irc.html#renaming-an-irc-channel I can probably help folks with that next week if desired. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From arne.wiebalck at cern.ch Fri Nov 27 17:35:49 2020 From: arne.wiebalck at cern.ch (Arne Wiebalck) Date: Fri, 27 Nov 2020 18:35:49 +0100 Subject: [ironic] [tripleo] RFC: lzma vs gzip for compressing IPA initramfs In-Reply-To: References: Message-ID: Hi, I did a quick test (one data point): - the image build time increased by 10 mins (on a VM, this is more than double compared to gzip) - but: the resulting image size is ~30% smaller (421 vs 297 MB) - the cleaning time (unpacking on bare metal!) increased by ~30 seconds So, lzma looks like a good option to reduce the image size which we had to do in our deployment already to address boot issues (we removed some packages). Keeping gzip as the default and offering lzma as an option to start with as suggested by Sergii seems like a good way forward. I also think it would be good to have someone else test as well to have another data point :-) Cheers, Arne On 27.11.20 14:00, Sergii Golovatiuk wrote: > Hi, > > LZMA causes very high CPU and memory usage for creating images, leaving > less resources for other processes. If Ironic is running alongside with > other services that may cause significant impact for them. I would leave > gzip option as default, would introduce --lzma as well as --gzip and use > lzma on 5-10% of our CI resources to test how it goes. Then after a > significant amount of testing we could turn it on as default. Proper > deprecation should be applied here as well IMHO. > > чт, 26 нояб. 2020 г. в 17:57, Dmitry Tantsur >: > > Hi folks, > > I've been playing with ways to reduce the size of our IPA images. > While package removals can only save us tens of megabytes, switching > from gzip to lzma reduces the size by around a third (from 373M to > 217M in my testing). > > What's the caveat? The unpacking time increases VERY substantially. > On my nested virt lab the 217M image took around 5 minutes to > unpack. I'm not sure how much it will impact real bare metal, please > feel free to test > https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/764371 > and tell me. > > So, what do you think? Switching to lzma by default will likely > affect CI run time (assuming we still have DIB jobs somewhere...) > and development environments, but it will also provide a visible > reduction in the image size (which benefit all environments). Large > TripleO images may particularly benefit from this (but also > particularly affected by the unpacking time). > > Feedback is very welcome. > > Dmitry > > -- > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, > Michael O'Neill > > > > -- > SergiiGolovatiuk > > Senior Software Developer > > Red Hat > > > From dangerzonen at gmail.com Fri Nov 27 01:01:12 2020 From: dangerzonen at gmail.com (dangerzone ar) Date: Fri, 27 Nov 2020 09:01:12 +0800 Subject: [openstack][neutron]How to establish existing Openstack in a single server to other multiple physical NIC port Message-ID: Hi, I have deployed packstack (All-In-One) openstack over single server and that openstack traffic is IN/Out via eth1 of the server and that's the network port configured during the packstack deployment. The server has 4 nic ports and only one (nic1) is used during openstack deployment. The openstack running good and my vm/vnf traffic can in/out via eth1. I would like to know how I can utilize other nic port (2,3,4) in my server so that openstack can leverage that port for my other VM/VNF that instantiate in my openstack. For example from the image attached, I want VM/VNF1 connect to nic2 and VM/VNF2 connect to nic3. Please advise how it can be done. I really hope someone could advise and help me further. Thank you. **This is standard openstack (deployed via packstack all-in-one) over single centos7 server that have 4 nic ports** -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openstack-vnf.jpg Type: image/jpeg Size: 41478 bytes Desc: not available URL: From smooney at redhat.com Fri Nov 27 18:42:51 2020 From: smooney at redhat.com (Sean Mooney) Date: Fri, 27 Nov 2020 18:42:51 +0000 Subject: [ironic] [tripleo] RFC: lzma vs gzip for compressing IPA initramfs In-Reply-To: References: Message-ID: <4f224519808b2662c49cd6b1799a84524b22d262.camel@redhat.com> On Fri, 2020-11-27 at 18:35 +0100, Arne Wiebalck wrote: > Hi, > > I did a quick test (one data point): > > - the image build time increased by 10 mins >    (on a VM, this is more than double compared to gzip) > - but: the resulting image size is ~30% smaller (421 vs 297 MB) > - the cleaning time (unpacking on bare metal!) increased by ~30 seconds > that is one of the main trade offs the lzma compression makes it front loads the computeational load to the comppression step requireing both more ram and time to do the initall compression while also achiviving a better compresison ratio while allowing light weight clients to decompress it without similar increase the time/ram requirement for the client. you may also want to consider the .xz format lzma and lzma2 have now been supperceed by .xz https://en.wikipedia.org/wiki/XZ_Utils .xz format is becomming more an d more commen fro things liek compress kernel modules and packages. > So, lzma looks like a good option to reduce the image size which > we had to do in our deployment already to address boot issues > (we removed some packages). > > Keeping gzip as the default and offering lzma as an option to > start with as suggested by Sergii seems like a good way forward. > > I also think it would be good to have someone else test as well > to have another data point :-) > > Cheers, >   Arne > > > On 27.11.20 14:00, Sergii Golovatiuk wrote: > > Hi, > > > > LZMA causes very high CPU and memory usage for creating images, leaving > > less resources for other processes. If Ironic is running alongside with > > other services that may cause significant impact for them. I would leave > > gzip option as default, would introduce --lzma as well as --gzip and use > > lzma on 5-10% of our CI resources to test how it goes. Then after a > > significant amount of testing we could turn it on as default. Proper > > deprecation should be applied here as well IMHO. > > > > чт, 26 нояб. 2020 г. в 17:57, Dmitry Tantsur > >: > > > >     Hi folks, > > > >     I've been playing with ways to reduce the size of our IPA images. > >     While package removals can only save us tens of megabytes, switching > >     from gzip to lzma reduces the size by around a third (from 373M to > >     217M in my testing). > > > >     What's the caveat? The unpacking time increases VERY substantially. > >     On my nested virt lab the 217M image took around 5 minutes to > >     unpack. I'm not sure how much it will impact real bare metal, please > >     feel free to test > >     https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/764371 > >     and tell me. > > > >     So, what do you think? Switching to lzma by default will likely > >     affect CI run time (assuming we still have DIB jobs somewhere...) > >     and development environments, but it will also provide a visible > >     reduction in the image size (which benefit all environments). Large > >     TripleO images may particularly benefit from this (but also > >     particularly affected by the unpacking time). > > > >     Feedback is very welcome. > > > >     Dmitry > > > >     -- > >     Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > >     Commercial register: Amtsgericht Muenchen, HRB 153243, > >     Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, > >     Michael O'Neill > > > > > > > > -- > > SergiiGolovatiuk > > > > Senior Software Developer > > > > Red Hat > > > > > > > From pramchan at yahoo.com Fri Nov 27 18:58:32 2020 From: pramchan at yahoo.com (prakash RAMCHANDRAN) Date: Fri, 27 Nov 2020 18:58:32 +0000 (UTC) Subject: [openstack] [InteropWG] Planning Approval by Nov 30th through email and later at Dec 8th Board meeting References: <847425537.2165756.1606503512836.ref@mail.yahoo.com> Message-ID: <847425537.2165756.1606503512836@mail.yahoo.com> Hi all, Hope you all had a good Thanks Giving and like to proceed from draft guidelines  on the VIctoria Interop to Approval at next Board meeting on Dec 8th. https://wiki.openstack.org/wiki/Governance/Foundation/8Dec2020BoardMeeting Please review the draft before Nov 30th Monday noon as we would like this 2020.11.* date maintained and will request an approval by Nov 30th, https://review.opendev.org/c/osf/interop/+/762719 The Interop WG meeting on Dec 3 , we will focus on maintenance of ReftStack and any additional discussions you like to bring for OIF InteropWG wrt add-on modules and or independent k8s conformance for Open Infrastructure Projects. https://etherpad.opendev.org/p/interop ThanksPrakash For InteropWG -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Fri Nov 27 23:19:47 2020 From: satish.txt at gmail.com (Satish Patel) Date: Fri, 27 Nov 2020 18:19:47 -0500 Subject: OVS-DPDK poor performance with Intel 82599 In-Reply-To: <3ab5f1bd48722c65994dc97ec884ca858934921e.camel@redhat.com> References: <05cc630458f1a7b62e14c7627f8784d38c7e5911.camel@redhat.com> <3ab5f1bd48722c65994dc97ec884ca858934921e.camel@redhat.com> Message-ID: Sean, Here is the full list of requested output : http://paste.openstack.org/show/800515/ In the above output I am noticing ovs_tx_failure_drops=38000 and at the same time Trex also showing me the same number of drops in its result. I will try to dig into ARP flood, you are saying ARP flood will be inside OVS switch right? any command or any specific thing i should look for? On Fri, Nov 27, 2020 at 8:49 AM Sean Mooney wrote: > > On Thu, 2020-11-26 at 22:10 -0500, Satish Patel wrote: > > Sean, > > > > Let me say "Happy Thanksgiving to you and your family". Thank you for > > taking time and reply, the last 2 days I was trying to find you on IRC > > to discuss this issue. Let me explain to you what I did so far. > > > > * First i did load-testing on my bare metal compute node to see how > > far my Trex can go and i found it Hit 2 million packet per second (Not > > sure if this is good result or not but it prove that i can hit at > > least 1 million pps) > for 64byte packets on that nic it should be hittihng about 11mpps on one core. > that said i have not validated that in a year or two but it could eaisly saturate 10G linerate with 64b > packest with 1 cores in the past. > > > > * Then i create sriov VM on that compute node with ( 8vCPU/8GB mem) > > and i re-run Trex and my max result was 323kpps without dropping > > packet) I found Intel 82599 nic VF only support 2 queue rx/tx and > > that could be bottleneck) > a VF can fully saturate the nic and hit 14.4 mpps if your cpu clock rate is fstat enough > > i.e. >3.2-3.5GHz on a 2.5GHz you porably wont hit that with 1 core but you shoudl get >10mpps > > > > > * Finally i decided to build DPDK vm on it and see how Trex behaved on > > it and i found it hit max ~400kpps with 4 PMD core. (little better > > than sriov because now i have 4 rx/tx queue thanks to 4 PMD core) > > ya so these number are far to low for a correctly complied and fuctioning trex binary > > > > > For Trex load-test i did statically assigned ARP entries because its > > part of Trex process to use static arp. > > > that wont work properly. if you do that the ovs bridge will not have its mac learning > table populated so it will flood packets. to do dpdk > > You are saying it should hit > > 11 million pps but question is what tools you guys using to hit that > > number i didn't see anyone using Trex for DPDK testing most of people > > using testpmd. > trex is a trafic generaotr orginally created by cisco i think > it often used in combination with testpmd. testpmd was desing to these the pool > mode driver as the name implice but its also uses as a replacement for a device/appliction > under test to messure the low level performacne in l2/l3 forading modes or basic mac swap mode. > > > > > > what kind of vm and (vCPU/memory people using to reach 11 million > > pps?) > > > > 2-4 vcpus with 2G or ram. > if dpdk is compile propertly and funtionion you dont need a lot of core although you will need > to use cpu pinning and hugepages for the vm and within the vm you will also need hugpeages if you are using dpdk there too. > > > I am stick to 8 vcpu because majority of my server has 8 core VM > > size so trying to get most of performance out of it.) > > > > If you have your load-test scenario available or tools available then > > please share some information so i will try to mimic that in my > > environment. thank you for reply. > > i think you need to start with getting trex to actully hit 10G linerate with small packets. > as i said you should not need more then about 2 cores to do that and 1-2 G of hugepages. > > once you have tha tworking you can move on to the rest but you need to ensure proper mac learning happens and arps are sent and replied > too before starting the traffic generattor so that floodign does not happen. > can you also provide the output of > > sudo ovs-vsctl list Open_vSwitch . > and the output of > sudo ovs-vsctl show, sudo ovs-vsctl list bridge, sudo ovs-vsctl list port and sudo ovs-vsctl list interface > > i just want to confirm that you have properly confiugred ovs-dpdk to use dpdk > > i dont work with dpdk that offent any more but i generally used testpmd in the guest with an ixia hardware traffic generator > to do performance messurments. i have used trex and it can hit line rate so im not sure why you are seeign such low performance. > > > > > ~S > > > > > > On Thu, Nov 26, 2020 at 8:14 PM Sean Mooney wrote: > > > > > > On Thu, 2020-11-26 at 16:56 -0500, Satish Patel wrote: > > > > Folks, > > > > > > > > I am playing with DPDK on my openstack with NIC model 82599 and seeing > > > > poor performance, i may be wrong with my numbers so want to see what > > > > the community thinks about these results. > > > > > > > > Compute node hardware: > > > > > > > > CPU: Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz > > > > Memory: 64G > > > > NIC: Intel 82599 (dual 10G port) > > > > > > > > [root at compute-lxb-3 ~]# ovs-vswitchd --version > > > > ovs-vswitchd (Open vSwitch) 2.13.2 > > > > DPDK 19.11.3 > > > > > > > > VM dpdk (DUT): > > > > 8vCPU / 8GB memory > > > > > > > > I have configured my computer node for all best practice available on > > > > the internet to get more performance out. > > > > > > > > 1. Used isolcpus to islocate CPUs > > > > 2. 4 dedicated core for PMD > > > > 3. echo isolated_cores=1,9,25,33 >> /etc/tuned/cpu-partitioning-variables.conf > > > > 4. Huge pages > > > > 5. CPU pinning for VM > > > > 6. increase ( ovs-vsctl set interface dpdk-1 options:n_rxq=4 ) > > > > 7. VM virtio_ring = 1024 > > > > > > > > After doing all above I am getting the following result using the Trex > > > > packet generator using 64B UDP stream (Total-PPS : 391.93 > > > > Kpps) Do you think it's an acceptable result or should it be higher > > > > on these NIC models? > > > that is one of inteles oldest generation 10G nics that is supported by dpdk > > > > > > but it shoudl still get to about 11 million packet per second with 1-2 cores > > > > > > my guess would be that the vm or trafic gerneator are not sentding and reciving mac learnign > > > frames like arp properly and as a result the packtes are flooding which will severly > > > reduce perfomance. > > > > > > > > On the internet folks say it should be a million packets per second so > > > > not sure what and how those people reached there or i am missing > > > > something in my load test profile. > > > > > > even kernel ovs will break a million packets persecond so 400Kpps is far to low > > > there is sometin gmisconfigred but im not sure what specificly form what you have shared. > > > as i said my best guess would be that the backets are flooding because the vm is not > > > responding to arp and the normal action is not learn the mac address. > > > > > > you could rule that out by adding hardcoded rules but you could also check the flow tables to confirm > > > > > > > > Notes: I am using 8vCPU core on VM do you think adding more cores will > > > > help? OR should i add more PMD? > > > > > > > > Cpu Utilization : 2.2 % 1.8 Gb/core > > > > Platform_factor : 1.0 > > > > Total-Tx : 200.67 Mbps > > > > Total-Rx : 200.67 Mbps > > > > Total-PPS : 391.93 Kpps > > > > Total-CPS : 391.89 Kcps > > > > > > > > Expected-PPS : 700.00 Kpps > > > > Expected-CPS : 700.00 Kcps > > > > Expected-BPS : 358.40 Mbps > > > > > > > > > > > > This is my all configuration: > > > > > > > > grub.conf: > > > > GRUB_CMDLINE_LINUX="vmalloc=384M crashkernel=auto > > > > rd.lvm.lv=rootvg01/lv01 console=ttyS1,118200 rhgb quiet intel_iommu=on > > > > iommu=pt spectre_v2=off nopti pti=off nospec_store_bypass_disable > > > > spec_store_bypass_disable=off l1tf=off default_hugepagesz=1GB > > > > hugepagesz=1G hugepages=60 transparent_hugepage=never selinux=0 > > > > isolcpus=2,3,4,5,6,7,10,11,12,13,14,15,26,27,28,29,30,31,34,35,36,37,38,39" > > > > > > > > > > > > [root at compute-lxb-3 ~]# ovs-appctl dpif/show > > > > netdev at ovs-netdev: hit:605860720 missed:2129 > > > > br-int: > > > > br-int 65534/3: (tap) > > > > int-br-vlan 1/none: (patch: peer=phy-br-vlan) > > > > patch-tun 2/none: (patch: peer=patch-int) > > > > vhu1d64ea7d-d9 5/6: (dpdkvhostuserclient: configured_rx_queues=8, > > > > configured_tx_queues=8, mtu=1500, requested_rx_queues=8, > > > > requested_tx_queues=8) > > > > vhu9c32faf6-ac 6/7: (dpdkvhostuserclient: configured_rx_queues=8, > > > > configured_tx_queues=8, mtu=1500, requested_rx_queues=8, > > > > requested_tx_queues=8) > > > > br-tun: > > > > br-tun 65534/4: (tap) > > > > patch-int 1/none: (patch: peer=patch-tun) > > > > vxlan-0a410071 2/5: (vxlan: egress_pkt_mark=0, key=flow, > > > > local_ip=10.65.0.114, remote_ip=10.65.0.113) > > > > br-vlan: > > > > br-vlan 65534/1: (tap) > > > > dpdk-1 2/2: (dpdk: configured_rx_queues=4, > > > > configured_rxq_descriptors=2048, configured_tx_queues=5, > > > > configured_txq_descriptors=2048, lsc_interrupt_mode=false, mtu=1500, > > > > requested_rx_queues=4, requested_rxq_descriptors=2048, > > > > requested_tx_queues=5, requested_txq_descriptors=2048, > > > > rx_csum_offload=true, tx_tso_offload=false) > > > > phy-br-vlan 1/none: (patch: peer=int-br-vlan) > > > > > > > > > > > > [root at compute-lxb-3 ~]# ovs-appctl dpif-netdev/pmd-rxq-show > > > > pmd thread numa_id 0 core_id 1: > > > > isolated : false > > > > port: dpdk-1 queue-id: 0 (enabled) pmd usage: 0 % > > > > port: vhu1d64ea7d-d9 queue-id: 3 (enabled) pmd usage: 0 % > > > > port: vhu1d64ea7d-d9 queue-id: 4 (enabled) pmd usage: 0 % > > > > port: vhu9c32faf6-ac queue-id: 3 (enabled) pmd usage: 0 % > > > > port: vhu9c32faf6-ac queue-id: 4 (enabled) pmd usage: 0 % > > > > pmd thread numa_id 0 core_id 9: > > > > isolated : false > > > > port: dpdk-1 queue-id: 1 (enabled) pmd usage: 0 % > > > > port: vhu1d64ea7d-d9 queue-id: 2 (enabled) pmd usage: 0 % > > > > port: vhu1d64ea7d-d9 queue-id: 5 (enabled) pmd usage: 0 % > > > > port: vhu9c32faf6-ac queue-id: 2 (enabled) pmd usage: 0 % > > > > port: vhu9c32faf6-ac queue-id: 5 (enabled) pmd usage: 0 % > > > > pmd thread numa_id 0 core_id 25: > > > > isolated : false > > > > port: dpdk-1 queue-id: 3 (enabled) pmd usage: 0 % > > > > port: vhu1d64ea7d-d9 queue-id: 0 (enabled) pmd usage: 0 % > > > > port: vhu1d64ea7d-d9 queue-id: 7 (enabled) pmd usage: 0 % > > > > port: vhu9c32faf6-ac queue-id: 0 (enabled) pmd usage: 0 % > > > > port: vhu9c32faf6-ac queue-id: 7 (enabled) pmd usage: 0 % > > > > pmd thread numa_id 0 core_id 33: > > > > isolated : false > > > > port: dpdk-1 queue-id: 2 (enabled) pmd usage: 0 % > > > > port: vhu1d64ea7d-d9 queue-id: 1 (enabled) pmd usage: 0 % > > > > port: vhu1d64ea7d-d9 queue-id: 6 (enabled) pmd usage: 0 % > > > > port: vhu9c32faf6-ac queue-id: 1 (enabled) pmd usage: 0 % > > > > port: vhu9c32faf6-ac queue-id: 6 (enabled) pmd usage: 0 % > > > > > > > > > > > > > > > > > From dtantsur at redhat.com Sat Nov 28 12:32:09 2020 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Sat, 28 Nov 2020 13:32:09 +0100 Subject: [ironic] [tripleo] RFC: lzma vs gzip for compressing IPA initramfs In-Reply-To: <4f224519808b2662c49cd6b1799a84524b22d262.camel@redhat.com> References: <4f224519808b2662c49cd6b1799a84524b22d262.camel@redhat.com> Message-ID: On Fri, Nov 27, 2020 at 7:46 PM Sean Mooney wrote: > On Fri, 2020-11-27 at 18:35 +0100, Arne Wiebalck wrote: > > Hi, > > > > I did a quick test (one data point): > > > > - the image build time increased by 10 mins > > (on a VM, this is more than double compared to gzip) > > - but: the resulting image size is ~30% smaller (421 vs 297 MB) > > - the cleaning time (unpacking on bare metal!) increased by ~30 seconds > > > that is one of the main trade offs the lzma compression makes > it front loads the computeational load to the comppression step > requireing both more ram and time to do the initall compression while > also achiviving a better compresison ratio while allowing light weight > clients to decompress it without similar increase the time/ram requirement > for the client. > you may also want to consider the .xz format > Is it wildly supported for initramfs compression? I can, of course, try, but maybe you know. Dmitry > > lzma and lzma2 have now been supperceed by .xz > https://en.wikipedia.org/wiki/XZ_Utils > > .xz format is becomming more an d more commen fro things liek compress > kernel modules and packages. > > > So, lzma looks like a good option to reduce the image size which > > we had to do in our deployment already to address boot issues > > (we removed some packages). > > > > Keeping gzip as the default and offering lzma as an option to > > start with as suggested by Sergii seems like a good way forward. > > > > I also think it would be good to have someone else test as well > > to have another data point :-) > > > > Cheers, > > Arne > > > > > > On 27.11.20 14:00, Sergii Golovatiuk wrote: > > > Hi, > > > > > > LZMA causes very high CPU and memory usage for creating images, > leaving > > > less resources for other processes. If Ironic is running alongside > with > > > other services that may cause significant impact for them. I would > leave > > > gzip option as default, would introduce --lzma as well as --gzip and > use > > > lzma on 5-10% of our CI resources to test how it goes. Then after a > > > significant amount of testing we could turn it on as default. Proper > > > deprecation should be applied here as well IMHO. > > > > > > чт, 26 нояб. 2020 г. в 17:57, Dmitry Tantsur > > >: > > > > > > Hi folks, > > > > > > I've been playing with ways to reduce the size of our IPA images. > > > While package removals can only save us tens of megabytes, > switching > > > from gzip to lzma reduces the size by around a third (from 373M to > > > 217M in my testing). > > > > > > What's the caveat? The unpacking time increases VERY substantially. > > > On my nested virt lab the 217M image took around 5 minutes to > > > unpack. I'm not sure how much it will impact real bare metal, > please > > > feel free to test > > > > https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/764371 > > > and tell me. > > > > > > So, what do you think? Switching to lzma by default will likely > > > affect CI run time (assuming we still have DIB jobs somewhere...) > > > and development environments, but it will also provide a visible > > > reduction in the image size (which benefit all environments). Large > > > TripleO images may particularly benefit from this (but also > > > particularly affected by the unpacking time). > > > > > > Feedback is very welcome. > > > > > > Dmitry > > > > > > -- > > > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > > > Commercial register: Amtsgericht Muenchen, HRB 153243, > > > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, > > > Michael O'Neill > > > > > > > > > > > > -- > > > SergiiGolovatiuk > > > > > > Senior Software Developer > > > > > > Red Hat > > > > > > > > > > > > > > > -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Sat Nov 28 14:12:44 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Sat, 28 Nov 2020 14:12:44 +0000 Subject: [ironic] [tripleo] RFC: lzma vs gzip for compressing IPA initramfs In-Reply-To: References: <4f224519808b2662c49cd6b1799a84524b22d262.camel@redhat.com> Message-ID: <20201128141243.ix56d4a5d5h6kyyt@yuggoth.org> On 2020-11-28 13:32:09 +0100 (+0100), Dmitry Tantsur wrote: > Is it wildly supported for initramfs compression? I can, of > course, try, but maybe you know. [...] It looks like you need your kernel built with with: CONFIG_HAVE_KERNEL_XZ=y CONFIG_KERNEL_XZ=y CONFIG_RD_XZ=y CONFIG_XZ_DEC=y CONFIG_XZ_DEC_X86=y (or relevant CPU architecture) CONFIG_DECOMPRESS_XZ=y The standard Linux 5.9 kernel on my Debian systems has the above enabled by default, not sure about other distros or older kernels though CONFIG_KERNEL_XZ has been included as far back as Linux 2.38: https://cateee.net/lkddb/web-lkddb/KERNEL_XZ.html Apparently you may need to pass --check=crc32 and (possibly --lzma2=dict=512KiB as well) to xz when compressing your initrd, to accommodate the kernel's decompressor implementation: https://github.com/linuxboot/book/blob/master/coreboot.u-root.systemboot/README.md#building-u-root https://www.linuxquestions.org/questions/slackware-installation-40/booting-with-xz-compressed-initrd-4175599273/ -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ts-takahashi at nec.com Mon Nov 30 03:00:21 2020 From: ts-takahashi at nec.com (=?utf-8?B?VEFLQUhBU0hJIFRPU0hJQUtJKOmrmOapi+OAgOaVj+aYjik=?=) Date: Mon, 30 Nov 2020 03:00:21 +0000 Subject: [tc][heat][tacker][tosca-parser][heat-translator] Discusssion about heat-translater and tosca-parser maintenance In-Reply-To: <1760a4b795a.10e369974791414.187901784754730298@ghanshyammann.com> References: <9aedf122-5ebb-e29a-d977-b58635cabe51@nokia.com> <1760a4b795a.10e369974791414.187901784754730298@ghanshyammann.com> Message-ID: Hi Bob, gmann, and Tacker team, Thank you for the reply. OK, first of all, our Tacker team will continue activities such as reviews so that we can work as a core of heat-translater and tosca-parser. For our team, there is no problem with our development if we can maintain the master code of those repo. How can we proceed with this? Should we give member names who will become core? Need to discuss with Heat, tc, etc.? And I'd like to continue to discuss other points such as cooperation with other members(Heat, or is there any users of those?). We will continue to talk about it in the Tacker team, and suggest again if there is some necessary discussion. Regards, Toshiaki > -----Original Message----- > From: Ghanshyam Mann > Sent: Saturday, November 28, 2020 12:21 AM > To: HADDLETON, Robert W (Bob) > Cc: openstack-discuss > Subject: Re: [tc][heat][tacker][tosca-parser][heat-translator] Discusssion about > heat-translater and tosca-parser maintenance > > ---- On Fri, 27 Nov 2020 09:09:41 -0600 HADDLETON, Robert W (Bob) > wrote ---- > @spzala and I have been maintaining, > as best we can, tosca-parser and > heat-translator for the past several years, > though our day jobs have > moved on to other things. This hasn't been a > problem because of the > extremely low activity in both projects, mostly > updating for releases > and handling a bug fix every once in a while. While > there has been a > flurry of new activity in the past week, we are unaware of any > issues in > these repos causing Tacker build failures or blocking any progress. > > > > I know I would be more than happy to add to the core team with the goal > of > eventually handing off maintenance responsibilities, and I'm pretty > sure > Sahdev will agree. > > > > I'll be back in the office next week, for about a week or so, then off > the rest > of the year. I'm glad to start discussions now and plan to > start making > changes in January, if that works. > > +1. That is a good idea to have more maintainer from the different team > +which is done > in much other repo too like horizon UI, devstack plugins repo. Both of these repos > are under the Heat project and Rico (heat PTL) also can help with this. > > -gmann > > > > > Thanks, > > > > Bob > > > > On 11/27/2020 7:15 AM, TAKAHASHI TOSHIAKI(高橋 敏明) wrote: > > > Hi, > > > > > > I'm a tacker team member. > > > I'd like to discuss how to maintain heat-translator[1] and tosca-parser[2] > repositories. > > > > > > These 2 repositories have not been updated so actively, but tacker often > requires code updates for these repositories. > > > Recently, patch merge progress of tacker and these repo do not sometimes > match, which affects the development of tacker. > > > For example, our some functional tests on zuul fail because these master > codes are not updated. > > > > > > Therefore, tacker members would like to take part more in these 2 > developments. > > > Tacker members have already started code reviews, patch posts, etc. > > > If possible, we want some Tacker members to join the core team in the near > future. > > > > > > How about this? > > > > > > [1] https://opendev.org/openstack/heat-translator > > > [2] https://opendev.org/openstack/tosca-parser > > > > > > > > > Regards, > > > Toshiaki > > > > > > > > > > From mrunge at matthias-runge.de Mon Nov 30 07:26:23 2020 From: mrunge at matthias-runge.de (Matthias Runge) Date: Mon, 30 Nov 2020 08:26:23 +0100 Subject: [telemetry] wallaby cycle planning session In-Reply-To: References: Message-ID: <20201130072623.GA71138@hilbert.berg.ol> On Thu, Nov 12, 2020 at 11:25:09AM +0100, Matthias Runge wrote: > Hi there, > > one of the biggest challenges for the telemetry stack is currently the state > of gnocchi, which is... undefined/unfortunate/under-contributed/...? Hi there, we had our planning/brainstorming, where we talked about the current state and the situation with gnocchi specifically. The situation can probably be described as: gnocchi fills a gap we couldn't satisfy to 100% if we would have to replace it. Also it is seen as well performing and functional. We also talked about the discussion around moving gnocchi back under openinfra and what this would solve. It is well understood, that the initial gnocchi project contributors are not paid for any work they do on gnocchi. We agreed to address the concern "we can not merge anything in gnocchi" by contributing to gnocchi for the next cycle and to revisit the situation next cycle. Julien, Mehdi and also Gord mentioned(iirc), that a bar for getting merge permission for a project with only a few contributors is quite low. A few PRs against gnocchi were mentioned, which were contributed but not reviewed/merged yet. * https://github.com/gnocchixyz/gnocchi/pull/1059 * https://github.com/gnocchixyz/gnocchi/pull/1062 * https://github.com/gnocchixyz/gnocchi/pull/1056 (this one was merged) * https://github.com/gnocchixyz/python-gnocchiclient/pull/104 We'll take a look and see how to proceed here. Gnocchis CI system apparently needs some work. On a related note, we are actively seeking to increase the collaboration with related projects or sigs, for example with CloudKitty. [1] https://etherpad.opendev.org/p/telemetry-wallaby-topics Matthias -- Matthias Runge From marios at redhat.com Mon Nov 30 07:33:25 2020 From: marios at redhat.com (Marios Andreou) Date: Mon, 30 Nov 2020 09:33:25 +0200 Subject: [ironic] [tripleo] RFC: lzma vs gzip for compressing IPA initramfs In-Reply-To: References: Message-ID: On Fri, Nov 27, 2020 at 3:16 PM Dmitry Tantsur wrote: > Hi, > > On Fri, Nov 27, 2020 at 2:00 PM Sergii Golovatiuk > wrote: > >> Hi, >> >> LZMA causes very high CPU and memory usage for creating images, leaving >> less resources for other processes. If Ironic is running alongside with >> other services that may cause significant impact for them. I would leave >> gzip option as default, would introduce --lzma as well as --gzip and use >> lzma on 5-10% of our CI resources to test how it goes. Then after a >> significant amount of testing we could turn it on as default. Proper >> deprecation should be applied here as well IMHO. >> > > +1 to make it optional. Five or even ten minutes (per the testing by Arne++ earlier in this thread) is a long time for some of the tripleo jobs which are running close to the 3 hour limit; for example we had to make some adjustment [1] recently for the standalone-upgrade job because of timeouts. > LZMA packing won't happen on ironic nodes. The images are pre-built and > only unpacked on the target machines. > > Or does TripleO build images every time? > No the CI jobs use images pulled from the ipa_image_url defined in [2] (that is for centos8 master, there are equivalent release files & image_url defined for the stable/*). Those are put there by the periodic buildimage-* jobs e.g. [3]. thanks, marios [1] https://review.opendev.org/c/openstack/tripleo-quickstart-extras/+/762674 [2] https://opendev.org/openstack/tripleo-quickstart/src/commit/fd092aa4b6a902381b3b700fdadb463649686067/config/release/tripleo-ci/CentOS-8/master.yml#L47 [3] https://review.rdoproject.org/zuul/builds?job_name=periodic-tripleo-centos-8-buildimage-ironic-python-agent-master&job_name=periodic-tripleo-centos-8-buildimage-overcloud-full-master > Dmitry > > >> >> чт, 26 нояб. 2020 г. в 17:57, Dmitry Tantsur : >> >>> Hi folks, >>> >>> I've been playing with ways to reduce the size of our IPA images. While >>> package removals can only save us tens of megabytes, switching from gzip to >>> lzma reduces the size by around a third (from 373M to 217M in my testing). >>> >>> What's the caveat? The unpacking time increases VERY substantially. On >>> my nested virt lab the 217M image took around 5 minutes to unpack. I'm not >>> sure how much it will impact real bare metal, please feel free to test >>> https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/764371 >>> and tell me. >>> >>> So, what do you think? Switching to lzma by default will likely affect >>> CI run time (assuming we still have DIB jobs somewhere...) and development >>> environments, but it will also provide a visible reduction in the image >>> size (which benefit all environments). Large TripleO images may >>> particularly benefit from this (but also particularly affected by the >>> unpacking time). >>> >>> Feedback is very welcome. >>> >>> Dmitry >>> >>> -- >>> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, >>> Commercial register: Amtsgericht Muenchen, HRB 153243, >>> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael >>> O'Neill >>> >> >> >> -- >> Sergii Golovatiuk >> >> Senior Software Developer >> >> Red Hat >> >> > > > -- > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael > O'Neill > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rico.lin.guanyu at gmail.com Mon Nov 30 07:34:01 2020 From: rico.lin.guanyu at gmail.com (Rico Lin) Date: Mon, 30 Nov 2020 15:34:01 +0800 Subject: [tc][heat][tacker][tosca-parser][heat-translator] Discusssion about heat-translater and tosca-parser maintenance In-Reply-To: References: <9aedf122-5ebb-e29a-d977-b58635cabe51@nokia.com> <1760a4b795a.10e369974791414.187901784754730298@ghanshyammann.com> Message-ID: On Mon, Nov 30, 2020 at 11:06 AM TAKAHASHI TOSHIAKI(高橋 敏明) < ts-takahashi at nec.com> wrote: > > Need to discuss with Heat, tc, etc.? > > And I'd like to continue to discuss other points such as cooperation with other members(Heat, or is there any users of those?). I don't think you need further discussion with tc as there still are ways for your patch to get reviewed, release package, or for you to join heat-translator-core team As we treat heat translator as a separated team, I'm definitely +1 on any decision from Bob. So not necessary to discuss with heat core team unless you find it difficult to achieve above tasks. I'm more than happy to provide help if needed. -- May The Force of OpenStack Be With You, Rico Lin irc: ricolin -------------- next part -------------- An HTML attachment was scrubbed... URL: From katonalala at gmail.com Mon Nov 30 07:50:54 2020 From: katonalala at gmail.com (Lajos Katona) Date: Mon, 30 Nov 2020 08:50:54 +0100 Subject: [openstack][neutron]How to establish existing Openstack in a single server to other multiple physical NIC port In-Reply-To: References: Message-ID: Hi, You can create provider nets, see for ovs: https://opendev.org/openstack/neutron/src/branch/master/doc/source/admin/deploy-ovs-provider.rst Regards Lajos dangerzone ar ezt írta (időpont: 2020. nov. 27., P, 18:54): > Hi, I have deployed packstack (All-In-One) openstack over single server > and that openstack traffic is IN/Out via eth1 of the server and that's the > network port configured during the packstack deployment. The server has 4 > nic ports and only one (nic1) is used during openstack deployment. The > openstack running good and my vm/vnf traffic can in/out via eth1. > I would like to know how I can utilize other nic port (2,3,4) in my server > so that openstack can leverage that port for my other VM/VNF that > instantiate in my openstack. For example from the image attached, I want > VM/VNF1 connect to nic2 and VM/VNF2 connect to nic3. > > Please advise how it can be done. I really hope someone could advise and > help me further. Thank you. > > **This is standard openstack (deployed via packstack all-in-one) over > single centos7 server that have 4 nic ports** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at est.tech Mon Nov 30 08:10:01 2020 From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer) Date: Mon, 30 Nov 2020 09:10:01 +0100 Subject: XDG_SESSION_TYPE error on devstack installation In-Reply-To: References: Message-ID: On Mon, Nov 30, 2020 at 12:21, Nitish Goel wrote: > Openstack devstack installation went fine after exporting " > XDG_SESSION_TYPE" but openstack cli didn't work I guess you need the XDG_SESSION_TYPE variable set in the env you are running the openstack CLI too. Cheers, gibi > > Thanks, > Nitish Goel > > On Thu, Nov 26, 2020 at 5:41 PM Nitish Goel > wrote: >> Thanks Balázs, >> >> This workaround export XDG_SESSION_TYPE='' worked for me. >> >> Thanks, >> Nitish Goel >> >> On Wed, Nov 25, 2020 at 10:07 PM Balázs Gibizer >> wrote: >>> >>> >>> On Wed, Nov 25, 2020 at 09:42, Nitish Goel >>> >>> wrote: >>> > Hi Team, >>> > >>> > I'm trying to install a devstack on a ubuntu 18.04 VM having >>> python >>> > 3.6.9 but getting below error. Any suggestions? >>> > python - 3.6.9 >>> > stack user with sudo access. >>> > pip version - pip 20.2.4 from >>> > /usr/local/lib/python3.6/dist-packages/pip (python 3.6) >>> > >>> https://stackoverflow.com/questions/64989221/xdg-session-type-error-on-devstack-installation >>> > NFO keystone.cmd.bootstrap [None >>> > req-f46e9c41-1b14-4e5b-82b2-ada81e8b0dcd None None] Created >>> region >>> > RegionOne >>> > INFO keystone.cmd.bootstrap [None >>> > req-f46e9c41-1b14-4e5b-82b2-ada81e8b0dcd None None] Created >>> public >>> > endpoint http://10.61.62.241/identity >>> > INFO keystone.cmd.bootstrap [None >>> > req-f46e9c41-1b14-4e5b-82b2-ada81e8b0dcd None None] Created admin >>> > endpoint http://10.61.62.241/identity >>> > >>> > >>> > +./stack.sh:main:1084 >>> create_keystone_accounts >>> > +lib/keystone:create_keystone_accounts:314 local admin_project >>> > ++lib/keystone:create_keystone_accounts:315 oscwrap project show >>> > admin -f value -c id >>> > Traceback (most recent call last): >>> > File "/usr/local/bin/openstack", line 5, in >>> > from openstackclient.shell import main >>> > File >>> > >>> "/usr/local/lib/python3.6/dist-packages/openstackclient/shell.py", >>> > line 24, in >>> > from osc_lib import shell >>> > File "/usr/local/lib/python3.6/dist-packages/osc_lib/shell.py", >>> > line 24, in >>> > from cliff import app >>> > File "/usr/local/lib/python3.6/dist-packages/cliff/app.py", >>> line >>> > 24, in >>> > import cmd2 >>> > File "/usr/local/lib/python3.6/dist-packages/cmd2/__init__.py", >>> > line 30, in >>> > from .cmd2 import Cmd >>> > File "/usr/local/lib/python3.6/dist-packages/cmd2/cmd2.py", >>> line >>> > 48, in >>> > from .clipboard import can_clip, get_paste_buffer, >>> > write_to_paste_buffer >>> > File >>> "/usr/local/lib/python3.6/dist-packages/cmd2/clipboard.py", >>> > line 12, in >>> > _ = pyperclip.paste() >>> > File >>> > "/usr/local/lib/python3.6/dist-packages/pyperclip/__init__.py", >>> line >>> > 680, in lazy_load_stub_paste >>> > copy, paste = determine_clipboard() >>> > File >>> > "/usr/local/lib/python3.6/dist-packages/pyperclip/__init__.py", >>> line >>> > 568, in determine_clipboard >>> > os.environ["XDG_SESSION_TYPE"] == "wayland" and >>> > File "/usr/lib/python3.6/os.py", line 669, in __getitem__ >>> > raise KeyError(key) from None >>> > KeyError: 'XDG_SESSION_TYPE' >>> > >>> > ++functions-common:oscwrap:2346 return 1 >>> > +lib/keystone:create_keystone_accounts:315 admin_project= >>> > +lib/keystone:create_keystone_accounts:1 exit_trap >>> > +./stack.sh:exit_trap:491 local r=1 >>> > ++./stack.sh:exit_trap:492 jobs -p >>> > +./stack.sh:exit_trap:492 jobs= >>> > +./stack.sh:exit_trap:495 [[ -n '' ]] >>> > +./stack.sh:exit_trap:501 '[' -f >>> /tmp/tmp.LRWsRkTTkV >>> > ']' >>> > +./stack.sh:exit_trap:502 rm /tmp/tmp.LRWsRkTTkV >>> > +./stack.sh:exit_trap:506 kill_spinner >>> > +./stack.sh:kill_spinner:401 '[' '!' -z '' ']' >>> > +./stack.sh:exit_trap:508 [[ 1 -ne 0 ]] >>> > +./stack.sh:exit_trap:509 echo 'Error on exit' >>> > Error on exit >>> > +./stack.sh:exit_trap:511 type -p >>> generate-subunit >>> > +./stack.sh:exit_trap:512 generate-subunit >>> > 1606228299 592 fail >>> > +./stack.sh:exit_trap:514 [[ -z /opt/stack/logs >>> ]] >>> > +./stack.sh:exit_trap:517 /usr/bin/python3.6 >>> > /opt/stack/devstack/tools/worlddump.py -d /opt/stack/logs >>> > +./stack.sh:exit_trap:526 exit 1 >>> >>> >>> I've seen the same error in my Ubuntu 18.04 devstack on master. I >>> stopped digging when I saw that the code that blows are 15 months >>> old[1]. As a workaround I did >>> >>> $ export XDG_SESSION_TYPE='' >>> $ ./unstack.sh && ./stack.sh >>> >>> And it worked. >>> >>> [1] >>> https://github.com/asweigart/pyperclip/blame/master/src/pyperclip/__init__.py#L568 >>> >>> Cheers, >>> gibi >>> >>> >>> >>> From ts-takahashi at nec.com Mon Nov 30 09:08:54 2020 From: ts-takahashi at nec.com (=?utf-8?B?VEFLQUhBU0hJIFRPU0hJQUtJKOmrmOapi+OAgOaVj+aYjik=?=) Date: Mon, 30 Nov 2020 09:08:54 +0000 Subject: [tc][heat][tacker][tosca-parser][heat-translator] Discusssion about heat-translater and tosca-parser maintenance In-Reply-To: References: <9aedf122-5ebb-e29a-d977-b58635cabe51@nokia.com> <1760a4b795a.10e369974791414.187901784754730298@ghanshyammann.com> Message-ID: Hi Rico, Thanks. OK, we’ll discuss with Bob to proceed with development of the projects. Regards, Toshiaki From: Rico Lin Sent: Monday, November 30, 2020 4:34 PM To: openstack-discuss Subject: Re: [tc][heat][tacker][tosca-parser][heat-translator] Discusssion about heat-translater and tosca-parser maintenance On Mon, Nov 30, 2020 at 11:06 AM TAKAHASHI TOSHIAKI(高橋　敏明) > wrote: > > Need to discuss with Heat, tc, etc.? > > And I'd like to continue to discuss other points such as cooperation with other members(Heat, or is there any users of those?). I don't think you need further discussion with tc as there still are ways for your patch to get reviewed, release package, or for you to join heat-translator-core team As we treat heat translator as a separated team, I'm definitely +1 on any decision from Bob. So not necessary to discuss with heat core team unless you find it difficult to achieve above tasks. I'm more than happy to provide help if needed. -- May The Force of OpenStack Be With You, Rico Lin irc: ricolin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at stackhpc.com Mon Nov 30 09:10:30 2020 From: mark at stackhpc.com (Mark Goddard) Date: Mon, 30 Nov 2020 09:10:30 +0000 Subject: [ironic] [tripleo] RFC: lzma vs gzip for compressing IPA initramfs In-Reply-To: References: Message-ID: On Fri, 27 Nov 2020 at 17:37, Arne Wiebalck wrote: > > Hi, > > I did a quick test (one data point): > > - the image build time increased by 10 mins > (on a VM, this is more than double compared to gzip) > - but: the resulting image size is ~30% smaller (421 vs 297 MB) > - the cleaning time (unpacking on bare metal!) increased by ~30 seconds 30 seconds is a long time, even for bare metal. 134 MB is roughly to a gigabit of network traffic. So really this comes down to how much spare capacity you have in your network to handle bursts of these downloads. > > So, lzma looks like a good option to reduce the image size which > we had to do in our deployment already to address boot issues > (we removed some packages). > > Keeping gzip as the default and offering lzma as an option to > start with as suggested by Sergii seems like a good way forward. > > I also think it would be good to have someone else test as well > to have another data point :-) > > Cheers, > Arne > > > On 27.11.20 14:00, Sergii Golovatiuk wrote: > > Hi, > > > > LZMA causes very high CPU and memory usage for creating images, leaving > > less resources for other processes. If Ironic is running alongside with > > other services that may cause significant impact for them. I would leave > > gzip option as default, would introduce --lzma as well as --gzip and use > > lzma on 5-10% of our CI resources to test how it goes. Then after a > > significant amount of testing we could turn it on as default. Proper > > deprecation should be applied here as well IMHO. > > > > чт, 26 нояб. 2020 г. в 17:57, Dmitry Tantsur > >: > > > > Hi folks, > > > > I've been playing with ways to reduce the size of our IPA images. > > While package removals can only save us tens of megabytes, switching > > from gzip to lzma reduces the size by around a third (from 373M to > > 217M in my testing). > > > > What's the caveat? The unpacking time increases VERY substantially. > > On my nested virt lab the 217M image took around 5 minutes to > > unpack. I'm not sure how much it will impact real bare metal, please > > feel free to test > > https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/764371 > > and tell me. > > > > So, what do you think? Switching to lzma by default will likely > > affect CI run time (assuming we still have DIB jobs somewhere...) > > and development environments, but it will also provide a visible > > reduction in the image size (which benefit all environments). Large > > TripleO images may particularly benefit from this (but also > > particularly affected by the unpacking time). > > > > Feedback is very welcome. > > > > Dmitry > > > > -- > > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > > Commercial register: Amtsgericht Muenchen, HRB 153243, > > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, > > Michael O'Neill > > > > > > > > -- > > SergiiGolovatiuk > > > > Senior Software Developer > > > > Red Hat > > > > > > > From arne.wiebalck at cern.ch Mon Nov 30 09:22:56 2020 From: arne.wiebalck at cern.ch (Arne Wiebalck) Date: Mon, 30 Nov 2020 10:22:56 +0100 Subject: [ironic] [tripleo] RFC: lzma vs gzip for compressing IPA initramfs In-Reply-To: References: Message-ID: <702e28ea-682b-a918-702f-6169fd840dee@cern.ch> On 30.11.20 10:10, Mark Goddard wrote: > On Fri, 27 Nov 2020 at 17:37, Arne Wiebalck wrote: >> >> Hi, >> >> I did a quick test (one data point): >> >> - the image build time increased by 10 mins >> (on a VM, this is more than double compared to gzip) >> - but: the resulting image size is ~30% smaller (421 vs 297 MB) >> - the cleaning time (unpacking on bare metal!) increased by ~30 seconds > > 30 seconds is a long time, even for bare metal. 134 MB is roughly to a > gigabit of network traffic. So really this comes down to how much > spare capacity you have in your network to handle bursts of these > downloads. From what I understand the main issue Dmitry is trying to address with this proposal is to reduce the risk of (UEFI) boot issues due to memory constraints on the target host. > >> >> So, lzma looks like a good option to reduce the image size which >> we had to do in our deployment already to address boot issues >> (we removed some packages). >> >> Keeping gzip as the default and offering lzma as an option to >> start with as suggested by Sergii seems like a good way forward. >> >> I also think it would be good to have someone else test as well >> to have another data point :-) >> >> Cheers, >> Arne >> >> >> On 27.11.20 14:00, Sergii Golovatiuk wrote: >>> Hi, >>> >>> LZMA causes very high CPU and memory usage for creating images, leaving >>> less resources for other processes. If Ironic is running alongside with >>> other services that may cause significant impact for them. I would leave >>> gzip option as default, would introduce --lzma as well as --gzip and use >>> lzma on 5-10% of our CI resources to test how it goes. Then after a >>> significant amount of testing we could turn it on as default. Proper >>> deprecation should be applied here as well IMHO. >>> >>> чт, 26 нояб. 2020 г. в 17:57, Dmitry Tantsur >> >: >>> >>> Hi folks, >>> >>> I've been playing with ways to reduce the size of our IPA images. >>> While package removals can only save us tens of megabytes, switching >>> from gzip to lzma reduces the size by around a third (from 373M to >>> 217M in my testing). >>> >>> What's the caveat? The unpacking time increases VERY substantially. >>> On my nested virt lab the 217M image took around 5 minutes to >>> unpack. I'm not sure how much it will impact real bare metal, please >>> feel free to test >>> https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/764371 >>> and tell me. >>> >>> So, what do you think? Switching to lzma by default will likely >>> affect CI run time (assuming we still have DIB jobs somewhere...) >>> and development environments, but it will also provide a visible >>> reduction in the image size (which benefit all environments). Large >>> TripleO images may particularly benefit from this (but also >>> particularly affected by the unpacking time). >>> >>> Feedback is very welcome. >>> >>> Dmitry >>> >>> -- >>> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, >>> Commercial register: Amtsgericht Muenchen, HRB 153243, >>> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, >>> Michael O'Neill >>> >>> >>> >>> -- >>> SergiiGolovatiuk >>> >>> Senior Software Developer >>> >>> Red Hat >>> >>> >>> >> From nicolas.parquet at gandi.net Mon Nov 30 09:35:37 2020 From: nicolas.parquet at gandi.net (Nicolas Parquet) Date: Mon, 30 Nov 2020 10:35:37 +0100 Subject: [cinder] Project ID in cinder endpoints and system scopes Message-ID: <5ded0a92-b6c0-8e58-667e-9184f2629f19@gandi.net> Hello there, Wondering if anyone has ongoing work or information on the following bug: https://bugs.launchpad.net/keystone/+bug/1745905 We tried removing the project_id from cinder endpoints in order to test system scopes and see if more is needed than oslo policy configuration, but cannot get anything else than 404 responses. The bug description suggests it is just a documentation issue, but I could not get a working setup. I also don't this mentioned in ptg documentation regarding system scopes support. Any information or hint is welcome! Regards, -- Nicolas Parquet Gandi nicolas.parquet at gandi.net From thierry at openstack.org Mon Nov 30 10:33:54 2020 From: thierry at openstack.org (Thierry Carrez) Date: Mon, 30 Nov 2020 11:33:54 +0100 Subject: [largescale-sig] Next meeting: December 2, 15utc Message-ID: <79158b30-cca1-e64c-db28-66e5637bb1fe@openstack.org> Hi everyone, We'll have a Large Scale SIG meeting this Wednesday in #openstack-meeting-3 on IRC, at 15UTC. You can doublecheck how it translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20201202T15 Our main topic will be to discuss how to best collect operator scaling experiences. Feel free to add other topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting Talk to you all later, -- Thierry Carrez From stephenfin at redhat.com Mon Nov 30 11:51:35 2020 From: stephenfin at redhat.com (Stephen Finucane) Date: Mon, 30 Nov 2020 11:51:35 +0000 Subject: [ops][nova][designate] Does anyone rely on fully-qualified instance names? Message-ID: When attaching a port to an instance, nova will check for DNS support in neutron and set a 'dns_name' attribute if found. To populate this attribute, nova uses a sanitised version of the instance name, stored in the instance.hostname attribute. This sanitisation simply strips out any unicode characters and replaces underscores and spaces with dashes, before truncating to 63 characters. It does not currently replace periods and this is the cause of bug 1581977 [1], where an instance name such as 'ubuntu20.04' will fail to schedule since neutron identifies '04' as an invalid TLD. The question now is what to do to resolve this. There are two obvious paths available to us. The first is to simply catch these invalid hostnames and replace them with an arbitrary hostname of format 'Server-{serverUUID}'. This is what we currently do for purely unicode instance names and is what I've proposed at [2]. The other option is to strip all periods, or rather replace them with hyphens, when sanitizing the instance name. This is more predictable but breaks the ability to use the instance name as a FQDN. Such usage is something I'm told we've never supported, but I'm concerned that there are users out there who are relying on this all the same and I'd like to get a feel for whether this is the case first. So, the question: does anyone currently rely on this inadvertent "feature"? Cheers, Stephen [1] https://launchpad.net/bugs/1581977 [2] https://review.opendev.org/c/openstack/nova/+/764482 From smooney at redhat.com Mon Nov 30 12:07:40 2020 From: smooney at redhat.com (Sean Mooney) Date: Mon, 30 Nov 2020 12:07:40 +0000 Subject: OVS-DPDK poor performance with Intel 82599 In-Reply-To: References: <05cc630458f1a7b62e14c7627f8784d38c7e5911.camel@redhat.com> <3ab5f1bd48722c65994dc97ec884ca858934921e.camel@redhat.com> Message-ID: <2d96461655c42d36a732948811204b82a364cffa.camel@redhat.com> On Fri, 2020-11-27 at 18:19 -0500, Satish Patel wrote: > Sean, > > Here is the full list of requested output : > http://paste.openstack.org/show/800515/ > > In the above output I am noticing ovs_tx_failure_drops=38000 and at > the same time Trex also showing me the same number of drops in its > result I will try to dig into ARP flood, you are saying ARP flood > will be inside OVS switch right? > looking at the packet stats for the other interfaces the switch is not flooing the traffic. the vhu port stats for vhu8710dd6b-e0 indicate that the vm is not reciving packets fast enough. so the vswitch (ovs-dpdk) needs to drop the packets. {ovs_rx_qos_drops=0, ovs_tx_failure_drops=38000, ovs_tx_invalid_hwol_drops=0, ovs_tx_mtu_exceeded_drops=0, ovs_tx_qos_drops=0, ovs_tx_retries=91, rx_1024_to_1522_packets=2, rx_128_to_255_packets=20, rx_1523_to_max_packets=0, rx_1_to_64_packets=27, rx_256_to_511_packets=24, rx_512_to_1023_packets=1, rx_65_to_127_packets=2379, rx_bytes=174105, rx_dropped=0, rx_errors=0, rx_packets=2453, tx_bytes=1088003898, tx_dropped=38000, tx_packets=17991999} based on num_of_vrings="16" i assume yo have enabeld virtio multi queue. have you also enabel that within the guest? older version of dpdk did not do negociation of which queue to enabel to if you did not enable all the queus in the guest it would cause really poor performance. in this case you have 8rx queues and 8 tx queues so you will want to ensure that trex in the the guest is using all 8 queues. dropping packets in dpdk is very expensive so even moderate drop rates negitivly impact its perfromace more then you would expect. each drop is baciclly a branch prodictor miss and cause the procesor to role back all its peculitive execution it also likely a cache miss as the drop code is marked as cold in the code so ya drop in dpdk are expensive as a result. > any command or any specific thing i > should look for? > > On Fri, Nov 27, 2020 at 8:49 AM Sean Mooney wrote: > > > > On Thu, 2020-11-26 at 22:10 -0500, Satish Patel wrote: > > > Sean, > > > > > > Let me say "Happy Thanksgiving to you and your family". Thank you for > > > taking time and reply, the last 2 days I was trying to find you on IRC > > > to discuss this issue. Let me explain to you what I did so far. > > > > > > * First i did load-testing on my bare metal compute node to see how > > > far my Trex can go and i found it Hit 2 million packet per second (Not > > > sure if this is good result or not but it prove that i can hit at > > > least 1 million pps) > > for 64byte packets on that nic it should be hittihng about 11mpps on one core. > > that said i have not validated that in a year or two but it could eaisly saturate 10G linerate with 64b > > packest with 1 cores in the past. > > > > > > * Then i create sriov VM on that compute node with ( 8vCPU/8GB mem) > > > and i re-run Trex and my max result was 323kpps without dropping > > > packet) I found Intel 82599 nic VF only support 2 queue rx/tx and > > > that could be bottleneck) > > a VF can fully saturate the nic and hit 14.4 mpps if your cpu clock rate is fstat enough > > > > i.e. >3.2-3.5GHz on a 2.5GHz you porably wont hit that with 1 core but you shoudl get >10mpps > > > > > > > > * Finally i decided to build DPDK vm on it and see how Trex behaved on > > > it and i found it hit max ~400kpps with 4 PMD core. (little better > > > than sriov because now i have 4 rx/tx queue thanks to 4 PMD core) > > > > ya so these number are far to low for a correctly complied and fuctioning trex binary > > > > > > > > For Trex load-test i did statically assigned ARP entries because its > > > part of Trex process to use static arp. > > > > > that wont work properly. if you do that the ovs bridge will not have its mac learning > > table populated so it will flood packets. to do dpdk > > > You are saying it should hit > > > 11 million pps but question is what tools you guys using to hit that > > > number i didn't see anyone using Trex for DPDK testing most of people > > > using testpmd. > > trex is a trafic generaotr orginally created by cisco i think > > it often used in combination with testpmd. testpmd was desing to these the pool > > mode driver as the name implice but its also uses as a replacement for a device/appliction > > under test to messure the low level performacne in l2/l3 forading modes or basic mac swap mode. > > > > > > > > > > what kind of vm and (vCPU/memory people using to reach 11 million > > > pps?) > > > > > > > 2-4 vcpus with 2G or ram. > > if dpdk is compile propertly and funtionion you dont need a lot of core although you will need > > to use cpu pinning and hugepages for the vm and within the vm you will also need hugpeages if you are using dpdk there too. > > > > >  I am stick to 8 vcpu because majority of my server has 8 core VM > > > size so trying to get most of performance out of it.) > > > > > > If you have your load-test scenario available or tools available then > > > please share some information so i will try to mimic that in my > > > environment. thank you for reply. > > > > i think you need to start with getting trex to actully hit 10G linerate with small packets. > > as i said you should not need more then about 2 cores to do that and 1-2 G of hugepages. > > > > once you have tha tworking you can move on to the rest but you need to ensure proper mac learning happens and arps are sent and replied > > too before starting the traffic generattor so that floodign does not happen. > > can you also provide the output of > > > > sudo ovs-vsctl list Open_vSwitch . > > and the output of > > sudo ovs-vsctl show, sudo ovs-vsctl list bridge, sudo ovs-vsctl list port and sudo ovs-vsctl list interface > > > > i just want to confirm that you have properly confiugred ovs-dpdk to use dpdk > > > > i dont work with dpdk that offent any more but i generally used testpmd in the guest with an ixia hardware traffic generator > > to do performance messurments. i have used trex and it can hit line rate so im not sure why you are seeign such low performance. > > > > > > > > ~S > > > > > > > > > On Thu, Nov 26, 2020 at 8:14 PM Sean Mooney wrote: > > > > > > > > On Thu, 2020-11-26 at 16:56 -0500, Satish Patel wrote: > > > > > Folks, > > > > > > > > > > I am playing with DPDK on my openstack with NIC model 82599 and seeing > > > > > poor performance, i may be wrong with my numbers so want to see what > > > > > the community thinks about these results. > > > > > > > > > > Compute node hardware: > > > > > > > > > > CPU: Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz > > > > > Memory: 64G > > > > > NIC: Intel 82599 (dual 10G port) > > > > > > > > > > [root at compute-lxb-3 ~]# ovs-vswitchd --version > > > > > ovs-vswitchd (Open vSwitch) 2.13.2 > > > > > DPDK 19.11.3 > > > > > > > > > > VM dpdk (DUT): > > > > > 8vCPU / 8GB memory > > > > > > > > > > I have configured my computer node for all best practice available on > > > > > the internet to get more performance out. > > > > > > > > > > 1. Used isolcpus to islocate CPUs > > > > > 2. 4 dedicated core for PMD > > > > > 3. echo isolated_cores=1,9,25,33 >> /etc/tuned/cpu-partitioning-variables.conf > > > > > 4. Huge pages > > > > > 5. CPU pinning for VM > > > > > 6. increase ( ovs-vsctl set interface dpdk-1 options:n_rxq=4 ) > > > > > 7. VM virtio_ring = 1024 > > > > > > > > > > After doing all above I am getting the following result using the Trex > > > > > packet generator using 64B UDP stream (Total-PPS : 391.93 > > > > > Kpps) Do you think it's an acceptable result or should it be higher > > > > > on these NIC models? > > > > that is one of inteles oldest generation 10G nics that is supported by dpdk > > > > > > > > but it shoudl still get to about 11 million packet per second with 1-2 cores > > > > > > > > my guess would be that the vm or trafic gerneator are not sentding and reciving mac learnign > > > > frames like arp properly and as a result the packtes are flooding which will severly > > > > reduce perfomance. > > > > > > > > > > On the internet folks say it should be a million packets per second so > > > > > not sure what and how those people reached there or i am missing > > > > > something in my load test profile. > > > > > > > > even kernel ovs will break a million packets persecond so 400Kpps is far to low > > > > there is sometin gmisconfigred but im not sure what specificly form what you have shared. > > > > as i said my best guess would be that the backets are flooding because the vm is not > > > > responding to arp and the normal action is not learn the mac address. > > > > > > > > you could rule that out by adding hardcoded rules but you could also check the flow tables to confirm > > > > > > > > > > Notes: I am using 8vCPU core on VM do you think adding more cores will > > > > > help? OR should i add more PMD? > > > > > > > > > > Cpu Utilization : 2.2 % 1.8 Gb/core > > > > >  Platform_factor : 1.0 > > > > >  Total-Tx : 200.67 Mbps > > > > >  Total-Rx : 200.67 Mbps > > > > >  Total-PPS : 391.93 Kpps > > > > >  Total-CPS : 391.89 Kcps > > > > > > > > > >  Expected-PPS : 700.00 Kpps > > > > >  Expected-CPS : 700.00 Kcps > > > > >  Expected-BPS : 358.40 Mbps > > > > > > > > > > > > > > > This is my all configuration: > > > > > > > > > > grub.conf: > > > > > GRUB_CMDLINE_LINUX="vmalloc=384M crashkernel=auto > > > > > rd.lvm.lv=rootvg01/lv01 console=ttyS1,118200 rhgb quiet intel_iommu=on > > > > > iommu=pt spectre_v2=off nopti pti=off nospec_store_bypass_disable > > > > > spec_store_bypass_disable=off l1tf=off default_hugepagesz=1GB > > > > > hugepagesz=1G hugepages=60 transparent_hugepage=never selinux=0 > > > > > isolcpus=2,3,4,5,6,7,10,11,12,13,14,15,26,27,28,29,30,31,34,35,36,37,38,39" > > > > > > > > > > > > > > > [root at compute-lxb-3 ~]# ovs-appctl dpif/show > > > > > netdev at ovs-netdev: hit:605860720 missed:2129 > > > > >   br-int: > > > > >     br-int 65534/3: (tap) > > > > >     int-br-vlan 1/none: (patch: peer=phy-br-vlan) > > > > >     patch-tun 2/none: (patch: peer=patch-int) > > > > >     vhu1d64ea7d-d9 5/6: (dpdkvhostuserclient: configured_rx_queues=8, > > > > > configured_tx_queues=8, mtu=1500, requested_rx_queues=8, > > > > > requested_tx_queues=8) > > > > >     vhu9c32faf6-ac 6/7: (dpdkvhostuserclient: configured_rx_queues=8, > > > > > configured_tx_queues=8, mtu=1500, requested_rx_queues=8, > > > > > requested_tx_queues=8) > > > > >   br-tun: > > > > >     br-tun 65534/4: (tap) > > > > >     patch-int 1/none: (patch: peer=patch-tun) > > > > >     vxlan-0a410071 2/5: (vxlan: egress_pkt_mark=0, key=flow, > > > > > local_ip=10.65.0.114, remote_ip=10.65.0.113) > > > > >   br-vlan: > > > > >     br-vlan 65534/1: (tap) > > > > >     dpdk-1 2/2: (dpdk: configured_rx_queues=4, > > > > > configured_rxq_descriptors=2048, configured_tx_queues=5, > > > > > configured_txq_descriptors=2048, lsc_interrupt_mode=false, mtu=1500, > > > > > requested_rx_queues=4, requested_rxq_descriptors=2048, > > > > > requested_tx_queues=5, requested_txq_descriptors=2048, > > > > > rx_csum_offload=true, tx_tso_offload=false) > > > > >     phy-br-vlan 1/none: (patch: peer=int-br-vlan) > > > > > > > > > > > > > > > [root at compute-lxb-3 ~]# ovs-appctl dpif-netdev/pmd-rxq-show > > > > > pmd thread numa_id 0 core_id 1: > > > > >   isolated : false > > > > >   port: dpdk-1 queue-id: 0 (enabled) pmd usage: 0 % > > > > >   port: vhu1d64ea7d-d9 queue-id: 3 (enabled) pmd usage: 0 % > > > > >   port: vhu1d64ea7d-d9 queue-id: 4 (enabled) pmd usage: 0 % > > > > >   port: vhu9c32faf6-ac queue-id: 3 (enabled) pmd usage: 0 % > > > > >   port: vhu9c32faf6-ac queue-id: 4 (enabled) pmd usage: 0 % > > > > > pmd thread numa_id 0 core_id 9: > > > > >   isolated : false > > > > >   port: dpdk-1 queue-id: 1 (enabled) pmd usage: 0 % > > > > >   port: vhu1d64ea7d-d9 queue-id: 2 (enabled) pmd usage: 0 % > > > > >   port: vhu1d64ea7d-d9 queue-id: 5 (enabled) pmd usage: 0 % > > > > >   port: vhu9c32faf6-ac queue-id: 2 (enabled) pmd usage: 0 % > > > > >   port: vhu9c32faf6-ac queue-id: 5 (enabled) pmd usage: 0 % > > > > > pmd thread numa_id 0 core_id 25: > > > > >   isolated : false > > > > >   port: dpdk-1 queue-id: 3 (enabled) pmd usage: 0 % > > > > >   port: vhu1d64ea7d-d9 queue-id: 0 (enabled) pmd usage: 0 % > > > > >   port: vhu1d64ea7d-d9 queue-id: 7 (enabled) pmd usage: 0 % > > > > >   port: vhu9c32faf6-ac queue-id: 0 (enabled) pmd usage: 0 % > > > > >   port: vhu9c32faf6-ac queue-id: 7 (enabled) pmd usage: 0 % > > > > > pmd thread numa_id 0 core_id 33: > > > > >   isolated : false > > > > >   port: dpdk-1 queue-id: 2 (enabled) pmd usage: 0 % > > > > >   port: vhu1d64ea7d-d9 queue-id: 1 (enabled) pmd usage: 0 % > > > > >   port: vhu1d64ea7d-d9 queue-id: 6 (enabled) pmd usage: 0 % > > > > >   port: vhu9c32faf6-ac queue-id: 1 (enabled) pmd usage: 0 % > > > > >   port: vhu9c32faf6-ac queue-id: 6 (enabled) pmd usage: 0 % > > > > > > > > > > > > > > > > > > > > > > > > > From smooney at redhat.com Mon Nov 30 12:16:15 2020 From: smooney at redhat.com (Sean Mooney) Date: Mon, 30 Nov 2020 12:16:15 +0000 Subject: [ops][nova][designate] Does anyone rely on fully-qualified instance names? In-Reply-To: References: Message-ID: On Mon, 2020-11-30 at 11:51 +0000, Stephen Finucane wrote: > When attaching a port to an instance, nova will check for DNS support in neutron > and set a 'dns_name' attribute if found. To populate this attribute, nova uses a > sanitised version of the instance name, stored in the instance.hostname > attribute. This sanitisation simply strips out any unicode characters and > replaces underscores and spaces with dashes, before truncating to 63 characters. > It does not currently replace periods and this is the cause of bug 1581977 [1], > where an instance name such as 'ubuntu20.04' will fail to schedule since neutron > identifies '04' as an invalid TLD. stripping out the unicode is actully incorrect behavior. hostname are allowed to contain unicode caraters. the asci subset is recommended but i would find that transfromation itself to be a bug in the implemation. its certenly not guarenteed to happen in the api and is not documented so it is not something people shoudl rely on in any way. > > The question now is what to do to resolve this. There are two obvious paths > available to us. The first is to simply catch these invalid hostnames and > replace them with an arbitrary hostname of format 'Server-{serverUUID}'. This is > what we currently do for purely unicode instance names and is what I've proposed > at [2]. The other option is to strip all periods, or rather replace them with > hyphens, when sanitizing the instance name. This is more predictable but breaks > the ability to use the instance name as a FQDN. Such usage is something I'm told > we've never supported, but I'm concerned that there are users out there who are > relying on this all the same and I'd like to get a feel for whether this is the > case first. > > So, the question: does anyone currently rely on this inadvertent "feature"? the other option is to return a 400 bad request and not do magic in the api. i would stongly prefer to not transform the users input in any way and require that they pass valid hostname which is what our current api constratit is and always has been. any usage of an FQDN previously was undfined behavior that may or may not have workd but was never actully allowed. i personally dont consider https://launchpad.net/bugs/1581977 to be a valid but outside of the fact we are not returning a 400 when you pass an FQDN. to do eather feature you describe above you would really need a spec if you want this to be part of the api contract as right now any sanitization or transfromation we do right now are not part fo the api garunetees. > > Cheers, > Stephen > > [1] https://launchpad.net/bugs/1581977 > [2] https://review.opendev.org/c/openstack/nova/+/764482 > > From fungi at yuggoth.org Mon Nov 30 13:34:55 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 30 Nov 2020 13:34:55 +0000 Subject: XDG_SESSION_TYPE error on devstack installation In-Reply-To: References: Message-ID: <20201130133454.webnwobne5ff3ptg@yuggoth.org> On 2020-11-30 09:10:01 +0100 (+0100), Balázs Gibizer wrote: > On Mon, Nov 30, 2020 at 12:21, Nitish Goel wrote: > > Openstack devstack installation went fine after exporting " > > XDG_SESSION_TYPE" but openstack cli didn't work > > I guess you need the XDG_SESSION_TYPE variable set in the env you are > running the openstack CLI too. [...] It looks like this problem was introduced roughly 6 weeks ago with the pyperclip 1.8.1 release. A fix was subsequently proposed, but doesn't seem to have been reviewed by the maintainer yet: https://github.com/asweigart/pyperclip/pull/177 Particularly unfortunate as that fix was proposed nearly a full week before the 1.8.1 release happened and could have been included. Now everyone is pinning to older versions or unnecessarily setting envvars in their systems to work around it, and the maintainer has fallen silent. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From fungi at yuggoth.org Mon Nov 30 13:58:30 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 30 Nov 2020 13:58:30 +0000 Subject: [ops][nova][designate] Does anyone rely on fully-qualified instance names? In-Reply-To: References: Message-ID: <20201130135830.q3fps4dwkxdiwngu@yuggoth.org> On 2020-11-30 11:51:35 +0000 (+0000), Stephen Finucane wrote: [...] > This is more predictable but breaks the ability to use the > instance name as a FQDN. Such usage is something I'm told we've > never supported, but I'm concerned that there are users out there > who are relying on this all the same and I'd like to get a feel > for whether this is the case first. > > So, the question: does anyone currently rely on this inadvertent > "feature"? [...] Just to be clear because I'm not entirely sure I follow the question: Are you asking whether users rely on being able to set FQDNs as instance names? Or are you asking whether users rely on Neutron setting those instance names automatically as DNS names? If it's the first, then yes lots of people (including my personal servers, as well as all of the control plane infrastructure for the OpenDev Collaboratory) enter the canonical DNS names of servers as their instance names. We don't rely on any direct DNS integration in our providers, but we do manually match instance names with address records in the relevant DNS zones we maintain. This also came up in another bug report recently, by the way: https://launchpad.net/bugs/1888722 -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From bdobreli at redhat.com Mon Nov 30 14:01:14 2020 From: bdobreli at redhat.com (Bogdan Dobrelya) Date: Mon, 30 Nov 2020 15:01:14 +0100 Subject: [all][infra] CI test result table in the new gerrit review UI Message-ID: <2dbd06c8-4837-dbda-0e5b-f485518c400c@redhat.com> Hi stackers, Until we have that pretty formatter for CI results, here's [0] a quick script instead. It queries Zuul CI comments by a given Gerrit SSH login and a patch set number, and colorizes it in your console outputs. PS. I'm sorry for top posting. [0] https://gist.github.com/bogdando/ed345b1f974c8e97edd33b61e7bf8158 > On Thu, 2020-11-26 at 17:30 +0000, Tristan Cacqueray wrote: >> On Thu, Nov 26, 2020 at 15:59 Sean Mooney wrote: >> > On Thu, 2020-11-26 at 15:19 +0000, Jeremy Stanley wrote: >> > > On 2020-11-26 15:10:09 +0000 (+0000), Tristan Cacqueray wrote: >> > > [...] >> > > > Here is a CR to add the test result table back in the new gerrit UI: >> > > > >> > > > https://review.opendev.org/c/opendev/system-config/+/763891 >> > > > >> > > > This new implementation uses the javascript plugin extension API. >> > > >> > > Thanks--that was quick work! >> >> You're welcome :) >> >> > is that going to be moved to the zuul org in opendev as a part of the zuul projects >> > deliverables. >> > >> > i kind of think it makes sne to develop it there rather then on the rdo gerrit instance. >> > >> >> I'd be happy to move the project to the opendev gerrit. >> >> > looking at the impleation it does not look like this owrks teh ssame way by parsing the comment >> > https://softwarefactory-project.io/cgit/software-factory/zuul-results-gerrit-plugin/tree/src/ZuulResultsPlugin.re#n115 >> > >> >> That is correct, this is using the Gerrit Js plugin api, which let you >> register a `showChange` callback, which is called with the change info >> https://gerrit-review.googlesource.com/Documentation/rest-api-changes.html#change-info >> >> Thus no need to hack through the dom to get the comments. >> >> Note that the gerrit related code is in another project here: >> https://softwarefactory-project.io/cgit/software-factory/re-gerrit/ >> >> > will this just show the results form zuul. it need to pars all the comments form the third party cis too. >> > basicaly you need to parse all coment form a author that end isn CI and comments form zuul >> >> It should do that already, though I haven't tested it with real data. I >> guess the next step would be to enable such plugin on review-dev. > so the author regular expression is only looking for zuul > https://softwarefactory-project.io/cgit/software-factory/re-gerrit/tree/src/CI.re#n41 > > so it lookes liek you would need to refactor that slightly to match comments form autors that end in ci too. > > each CI systems comemtn then need have there won tabel section with the job results for that ci to mimic the same behavior > we had in the old ui. > > >> >> Cheers, >> -Tristan -- Best regards, Bogdan Dobrelya, Irc #bogdando From oleg.bondarev at huawei.com Mon Nov 30 14:17:47 2020 From: oleg.bondarev at huawei.com (Oleg Bondarev) Date: Mon, 30 Nov 2020 14:17:47 +0000 Subject: [neutron] bug deputy report Nov 23-29 Message-ID: <6f87beef29314934ba65186d42ccb8b6@huawei.com> Please find new bugs summary for the week Nov 23-27. Nothing critical. 2 RFEs for neutron drivers team to discuss. High: - https://bugs.launchpad.net/neutron/+bug/1905700 - [OVN] ovn-metadata-agent: "RowNotFound: Cannot find Chassis with name..." when starting the agent - Gate failure - fix approved: https://review.opendev.org/c/openstack/neutron/+/764318 - https://bugs.launchpad.net/neutron/+bug/1905726 - Qos plugin performs too many queries - fixes on review: - https://review.opendev.org/c/openstack/neutron/+/764433 - https://review.opendev.org/c/openstack/neutron/+/764454 Medium: - https://bugs.launchpad.net/neutron/+bug/1905271 - [OVS] Polling cycle continuously interrupted by L2 population (when enabled) - fix on review: https://review.opendev.org/c/openstack/neutron/+/755313 - https://bugs.launchpad.net/neutron/+bug/1905551 - functional: test_gateway_chassis_rebalance fails - Unassigned - https://bugs.launchpad.net/neutron/+bug/1905568 - Sanity checks missing port_name while adding tunnel port - fix approved: https://review.opendev.org/c/openstack/neutron/+/764171 - https://bugs.launchpad.net/neutron/+bug/1905611 - OVN.ovsdb_probe_interval takes effect only after initial database dump - Unassigned Low: - https://bugs.launchpad.net/neutron/+bug/1905538 - Some OVS bridges may lack OpenFlow10 protocol - fix on review: https://review.opendev.org/c/openstack/neutron/+/764150 Wishlist: - https://bugs.launchpad.net/neutron/+bug/1905276 - Overriding hypervisor name for resource provider always requires a complete list of interfaces/bridges - fix on review - https://review.opendev.org/c/openstack/neutron/+/763563 - https://bugs.launchpad.net/neutron/+bug/1905268 - port list performance for trunks can be optimized - fix on review - https://review.opendev.org/c/openstack/neutron/+/763777 RFEs: - https://bugs.launchpad.net/neutron/+bug/1905295 - [RFE] Allow multiple external gateways on a router - https://bugs.launchpad.net/neutron/+bug/1905391 - [RFE] VPNaaS support for OVN Won't fix: - https://bugs.launchpad.net/neutron/+bug/1905552 - neutron-fwaas netlink conntrack driver would catch error while conntrack rules protocol is 'unknown' - fwaas is not supported Expired Bugs: - https://bugs.launchpad.net/bugs/1896592 - [neutron-tempest-plugin] test_dhcpv6_stateless_* clashing when creating a IPv6 subnet - https://bugs.launchpad.net/bugs/1853632 - designate dns driver does not use domain settings for auth Thanks, Oleg --- Advanced Software Technology Lab Huawei -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Mon Nov 30 14:38:31 2020 From: satish.txt at gmail.com (Satish Patel) Date: Mon, 30 Nov 2020 09:38:31 -0500 Subject: OVS-DPDK poor performance with Intel 82599 In-Reply-To: <2d96461655c42d36a732948811204b82a364cffa.camel@redhat.com> References: <05cc630458f1a7b62e14c7627f8784d38c7e5911.camel@redhat.com> <3ab5f1bd48722c65994dc97ec884ca858934921e.camel@redhat.com> <2d96461655c42d36a732948811204b82a364cffa.camel@redhat.com> Message-ID: Good morning sean, Yes I do have multi-queue enabled and on guests by default I am seeing 8 queues. see following output. [root at c8-dpdk ~]# ethtool -l eth0 Channel parameters for eth0: Pre-set maximums: RX: 0 TX: 0 Other: 0 Combined: 8 Current hardware settings: RX: 0 TX: 0 Other: 0 Combined: 8 If you noticed i have 8 queue on VM but only 4 queue is active and other 4 doing nothing i believe because i have only 4 PMD threads and my vswitch is configured for (configured_rx_queues=4) [root at compute-lxb-3 ~]# ovs-vsctl set interface dpdk-1 options:n_rxq=4 Here is the real-time VM queue stats [root at c8-dpdk ~]# ethtool -S eth0 NIC statistics: rx_queue_0_packets: 0 rx_queue_0_bytes: 0 rx_queue_1_packets: 369536869 rx_queue_1_bytes: 262805118523 rx_queue_2_packets: 106161912 rx_queue_2_bytes: 18047524850 rx_queue_3_packets: 106111697 rx_queue_3_bytes: 18038988269 rx_queue_4_packets: 368173238 rx_queue_4_bytes: 262783235737 rx_queue_5_packets: 0 rx_queue_5_bytes: 0 rx_queue_6_packets: 0 rx_queue_6_bytes: 0 rx_queue_7_packets: 0 rx_queue_7_bytes: 0 tx_queue_0_packets: 48 tx_queue_0_bytes: 7225 tx_queue_1_packets: 277191537 tx_queue_1_bytes: 64323249610 tx_queue_2_packets: 308945384 tx_queue_2_bytes: 66342845029 tx_queue_3_packets: 116130494 tx_queue_3_bytes: 31497220898 tx_queue_4_packets: 4599 tx_queue_4_bytes: 280111 tx_queue_5_packets: 1068 tx_queue_5_bytes: 89631 tx_queue_6_packets: 1106 tx_queue_6_bytes: 83642 tx_queue_7_packets: 108513710 tx_queue_7_bytes: 31040692056 I am noticing during load-test CPU interrupt going high on VM guest so i believe my CPU running out of gas (because on VM i am not running DPDK application and every single packet getting processed by kernel, do you think that could be issue) [root at c8-dpdk ~]# vmstat -n 1 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 3244980 2668 400820 0 0 0 0 12 5 0 0 100 0 0 0 0 0 3243828 2668 400820 0 0 0 0 95518 2990 0 24 76 0 0 0 0 0 3243988 2668 400820 0 0 0 0 95417 2986 0 24 76 0 0 0 0 0 3244884 2668 400836 0 0 0 0 90471 2901 0 23 77 0 0 0 0 0 3244756 2668 400836 0 0 0 0 84658 2733 0 24 76 0 0 0 0 0 3244468 2668 400836 0 0 0 0 95634 2974 0 24 76 0 0 0 0 0 3243732 2668 400836 0 0 0 0 95033 3010 0 24 76 0 0 0 0 0 3244276 2668 400836 0 0 0 0 94840 2986 0 24 76 0 0 0 0 0 3244596 2668 400836 0 0 0 0 98760 3114 0 24 76 0 0 0 0 0 3244284 2668 400836 0 0 0 0 88780 2795 0 24 76 0 0 0 0 0 3244956 2668 400836 0 0 0 0 87878 2756 0 24 76 0 0 I am getting the same result on the SR-IOV guest VM (it has nothing to do with DPDK) . I believe it is my NIC or kernel limitation. Intel 82599 only support 2 queue for VF check out this link https://community.intel.com/t5/Ethernet-Products/Intel-NIC-82599-EB-enable-SR-IOV-and-multiqueue/td-p/387696 Currently my Trex is sending packet to port0 and receiving packet from port1 (my VM guest just forwarding packet from eth0 to eth1). Do you think i should use testpmd on guest VM to boost packet forwarding from interface a to b ? On Mon, Nov 30, 2020 at 7:07 AM Sean Mooney wrote: > > On Fri, 2020-11-27 at 18:19 -0500, Satish Patel wrote: > > Sean, > > > > Here is the full list of requested output : > > http://paste.openstack.org/show/800515/ > > > > In the above output I am noticing ovs_tx_failure_drops=38000 and at > > the same time Trex also showing me the same number of drops in its > > result I will try to dig into ARP flood, you are saying ARP flood > > will be inside OVS switch right? > > > looking at the packet stats for the other interfaces the switch is not flooing the > traffic. > > the vhu port stats for vhu8710dd6b-e0 indicate that the vm is not reciving packets fast enough. > so the vswitch (ovs-dpdk) needs to drop the packets. > {ovs_rx_qos_drops=0, ovs_tx_failure_drops=38000, ovs_tx_invalid_hwol_drops=0, ovs_tx_mtu_exceeded_drops=0, ovs_tx_qos_drops=0, ovs_tx_retries=91, > rx_1024_to_1522_packets=2, rx_128_to_255_packets=20, rx_1523_to_max_packets=0, rx_1_to_64_packets=27, rx_256_to_511_packets=24, > rx_512_to_1023_packets=1, rx_65_to_127_packets=2379, rx_bytes=174105, rx_dropped=0, rx_errors=0, rx_packets=2453, tx_bytes=1088003898, > tx_dropped=38000, tx_packets=17991999} > > based on num_of_vrings="16" i assume yo have enabeld virtio multi queue. > have you also enabel that within the guest? > > older version of dpdk did not do negociation of which queue to enabel to if you did not enable all the queus in the guest it would cause really poor > performance. > > in this case you have 8rx queues and 8 tx queues so you will want to ensure that trex in the the guest is using all 8 queues. > > dropping packets in dpdk is very expensive so even moderate drop rates negitivly impact its perfromace more then you would expect. > each drop is baciclly a branch prodictor miss and cause the procesor to role back all its peculitive execution it also likely a cache miss as > the drop code is marked as cold in the code so ya drop in dpdk are expensive as a result. > > > any command or any specific thing i > > should look for? > > > > On Fri, Nov 27, 2020 at 8:49 AM Sean Mooney wrote: > > > > > > On Thu, 2020-11-26 at 22:10 -0500, Satish Patel wrote: > > > > Sean, > > > > > > > > Let me say "Happy Thanksgiving to you and your family". Thank you for > > > > taking time and reply, the last 2 days I was trying to find you on IRC > > > > to discuss this issue. Let me explain to you what I did so far. > > > > > > > > * First i did load-testing on my bare metal compute node to see how > > > > far my Trex can go and i found it Hit 2 million packet per second (Not > > > > sure if this is good result or not but it prove that i can hit at > > > > least 1 million pps) > > > for 64byte packets on that nic it should be hittihng about 11mpps on one core. > > > that said i have not validated that in a year or two but it could eaisly saturate 10G linerate with 64b > > > packest with 1 cores in the past. > > > > > > > > * Then i create sriov VM on that compute node with ( 8vCPU/8GB mem) > > > > and i re-run Trex and my max result was 323kpps without dropping > > > > packet) I found Intel 82599 nic VF only support 2 queue rx/tx and > > > > that could be bottleneck) > > > a VF can fully saturate the nic and hit 14.4 mpps if your cpu clock rate is fstat enough > > > > > > i.e. >3.2-3.5GHz on a 2.5GHz you porably wont hit that with 1 core but you shoudl get >10mpps > > > > > > > > > > > * Finally i decided to build DPDK vm on it and see how Trex behaved on > > > > it and i found it hit max ~400kpps with 4 PMD core. (little better > > > > than sriov because now i have 4 rx/tx queue thanks to 4 PMD core) > > > > > > ya so these number are far to low for a correctly complied and fuctioning trex binary > > > > > > > > > > > For Trex load-test i did statically assigned ARP entries because its > > > > part of Trex process to use static arp. > > > > > > > that wont work properly. if you do that the ovs bridge will not have its mac learning > > > table populated so it will flood packets. to do dpdk > > > > You are saying it should hit > > > > 11 million pps but question is what tools you guys using to hit that > > > > number i didn't see anyone using Trex for DPDK testing most of people > > > > using testpmd. > > > trex is a trafic generaotr orginally created by cisco i think > > > it often used in combination with testpmd. testpmd was desing to these the pool > > > mode driver as the name implice but its also uses as a replacement for a device/appliction > > > under test to messure the low level performacne in l2/l3 forading modes or basic mac swap mode. > > > > > > > > > > > > > > what kind of vm and (vCPU/memory people using to reach 11 million > > > > pps?) > > > > > > > > > > 2-4 vcpus with 2G or ram. > > > if dpdk is compile propertly and funtionion you dont need a lot of core although you will need > > > to use cpu pinning and hugepages for the vm and within the vm you will also need hugpeages if you are using dpdk there too. > > > > > > > I am stick to 8 vcpu because majority of my server has 8 core VM > > > > size so trying to get most of performance out of it.) > > > > > > > > If you have your load-test scenario available or tools available then > > > > please share some information so i will try to mimic that in my > > > > environment. thank you for reply. > > > > > > i think you need to start with getting trex to actully hit 10G linerate with small packets. > > > as i said you should not need more then about 2 cores to do that and 1-2 G of hugepages. > > > > > > once you have tha tworking you can move on to the rest but you need to ensure proper mac learning happens and arps are sent and replied > > > too before starting the traffic generattor so that floodign does not happen. > > > can you also provide the output of > > > > > > sudo ovs-vsctl list Open_vSwitch . > > > and the output of > > > sudo ovs-vsctl show, sudo ovs-vsctl list bridge, sudo ovs-vsctl list port and sudo ovs-vsctl list interface > > > > > > i just want to confirm that you have properly confiugred ovs-dpdk to use dpdk > > > > > > i dont work with dpdk that offent any more but i generally used testpmd in the guest with an ixia hardware traffic generator > > > to do performance messurments. i have used trex and it can hit line rate so im not sure why you are seeign such low performance. > > > > > > > > > > > ~S > > > > > > > > > > > > On Thu, Nov 26, 2020 at 8:14 PM Sean Mooney wrote: > > > > > > > > > > On Thu, 2020-11-26 at 16:56 -0500, Satish Patel wrote: > > > > > > Folks, > > > > > > > > > > > > I am playing with DPDK on my openstack with NIC model 82599 and seeing > > > > > > poor performance, i may be wrong with my numbers so want to see what > > > > > > the community thinks about these results. > > > > > > > > > > > > Compute node hardware: > > > > > > > > > > > > CPU: Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz > > > > > > Memory: 64G > > > > > > NIC: Intel 82599 (dual 10G port) > > > > > > > > > > > > [root at compute-lxb-3 ~]# ovs-vswitchd --version > > > > > > ovs-vswitchd (Open vSwitch) 2.13.2 > > > > > > DPDK 19.11.3 > > > > > > > > > > > > VM dpdk (DUT): > > > > > > 8vCPU / 8GB memory > > > > > > > > > > > > I have configured my computer node for all best practice available on > > > > > > the internet to get more performance out. > > > > > > > > > > > > 1. Used isolcpus to islocate CPUs > > > > > > 2. 4 dedicated core for PMD > > > > > > 3. echo isolated_cores=1,9,25,33 >> /etc/tuned/cpu-partitioning-variables.conf > > > > > > 4. Huge pages > > > > > > 5. CPU pinning for VM > > > > > > 6. increase ( ovs-vsctl set interface dpdk-1 options:n_rxq=4 ) > > > > > > 7. VM virtio_ring = 1024 > > > > > > > > > > > > After doing all above I am getting the following result using the Trex > > > > > > packet generator using 64B UDP stream (Total-PPS : 391.93 > > > > > > Kpps) Do you think it's an acceptable result or should it be higher > > > > > > on these NIC models? > > > > > that is one of inteles oldest generation 10G nics that is supported by dpdk > > > > > > > > > > but it shoudl still get to about 11 million packet per second with 1-2 cores > > > > > > > > > > my guess would be that the vm or trafic gerneator are not sentding and reciving mac learnign > > > > > frames like arp properly and as a result the packtes are flooding which will severly > > > > > reduce perfomance. > > > > > > > > > > > > On the internet folks say it should be a million packets per second so > > > > > > not sure what and how those people reached there or i am missing > > > > > > something in my load test profile. > > > > > > > > > > even kernel ovs will break a million packets persecond so 400Kpps is far to low > > > > > there is sometin gmisconfigred but im not sure what specificly form what you have shared. > > > > > as i said my best guess would be that the backets are flooding because the vm is not > > > > > responding to arp and the normal action is not learn the mac address. > > > > > > > > > > you could rule that out by adding hardcoded rules but you could also check the flow tables to confirm > > > > > > > > > > > > Notes: I am using 8vCPU core on VM do you think adding more cores will > > > > > > help? OR should i add more PMD? > > > > > > > > > > > > Cpu Utilization : 2.2 % 1.8 Gb/core > > > > > > Platform_factor : 1.0 > > > > > > Total-Tx : 200.67 Mbps > > > > > > Total-Rx : 200.67 Mbps > > > > > > Total-PPS : 391.93 Kpps > > > > > > Total-CPS : 391.89 Kcps > > > > > > > > > > > > Expected-PPS : 700.00 Kpps > > > > > > Expected-CPS : 700.00 Kcps > > > > > > Expected-BPS : 358.40 Mbps > > > > > > > > > > > > > > > > > > This is my all configuration: > > > > > > > > > > > > grub.conf: > > > > > > GRUB_CMDLINE_LINUX="vmalloc=384M crashkernel=auto > > > > > > rd.lvm.lv=rootvg01/lv01 console=ttyS1,118200 rhgb quiet intel_iommu=on > > > > > > iommu=pt spectre_v2=off nopti pti=off nospec_store_bypass_disable > > > > > > spec_store_bypass_disable=off l1tf=off default_hugepagesz=1GB > > > > > > hugepagesz=1G hugepages=60 transparent_hugepage=never selinux=0 > > > > > > isolcpus=2,3,4,5,6,7,10,11,12,13,14,15,26,27,28,29,30,31,34,35,36,37,38,39" > > > > > > > > > > > > > > > > > > [root at compute-lxb-3 ~]# ovs-appctl dpif/show > > > > > > netdev at ovs-netdev: hit:605860720 missed:2129 > > > > > > br-int: > > > > > > br-int 65534/3: (tap) > > > > > > int-br-vlan 1/none: (patch: peer=phy-br-vlan) > > > > > > patch-tun 2/none: (patch: peer=patch-int) > > > > > > vhu1d64ea7d-d9 5/6: (dpdkvhostuserclient: configured_rx_queues=8, > > > > > > configured_tx_queues=8, mtu=1500, requested_rx_queues=8, > > > > > > requested_tx_queues=8) > > > > > > vhu9c32faf6-ac 6/7: (dpdkvhostuserclient: configured_rx_queues=8, > > > > > > configured_tx_queues=8, mtu=1500, requested_rx_queues=8, > > > > > > requested_tx_queues=8) > > > > > > br-tun: > > > > > > br-tun 65534/4: (tap) > > > > > > patch-int 1/none: (patch: peer=patch-tun) > > > > > > vxlan-0a410071 2/5: (vxlan: egress_pkt_mark=0, key=flow, > > > > > > local_ip=10.65.0.114, remote_ip=10.65.0.113) > > > > > > br-vlan: > > > > > > br-vlan 65534/1: (tap) > > > > > > dpdk-1 2/2: (dpdk: configured_rx_queues=4, > > > > > > configured_rxq_descriptors=2048, configured_tx_queues=5, > > > > > > configured_txq_descriptors=2048, lsc_interrupt_mode=false, mtu=1500, > > > > > > requested_rx_queues=4, requested_rxq_descriptors=2048, > > > > > > requested_tx_queues=5, requested_txq_descriptors=2048, > > > > > > rx_csum_offload=true, tx_tso_offload=false) > > > > > > phy-br-vlan 1/none: (patch: peer=int-br-vlan) > > > > > > > > > > > > > > > > > > [root at compute-lxb-3 ~]# ovs-appctl dpif-netdev/pmd-rxq-show > > > > > > pmd thread numa_id 0 core_id 1: > > > > > > isolated : false > > > > > > port: dpdk-1 queue-id: 0 (enabled) pmd usage: 0 % > > > > > > port: vhu1d64ea7d-d9 queue-id: 3 (enabled) pmd usage: 0 % > > > > > > port: vhu1d64ea7d-d9 queue-id: 4 (enabled) pmd usage: 0 % > > > > > > port: vhu9c32faf6-ac queue-id: 3 (enabled) pmd usage: 0 % > > > > > > port: vhu9c32faf6-ac queue-id: 4 (enabled) pmd usage: 0 % > > > > > > pmd thread numa_id 0 core_id 9: > > > > > > isolated : false > > > > > > port: dpdk-1 queue-id: 1 (enabled) pmd usage: 0 % > > > > > > port: vhu1d64ea7d-d9 queue-id: 2 (enabled) pmd usage: 0 % > > > > > > port: vhu1d64ea7d-d9 queue-id: 5 (enabled) pmd usage: 0 % > > > > > > port: vhu9c32faf6-ac queue-id: 2 (enabled) pmd usage: 0 % > > > > > > port: vhu9c32faf6-ac queue-id: 5 (enabled) pmd usage: 0 % > > > > > > pmd thread numa_id 0 core_id 25: > > > > > > isolated : false > > > > > > port: dpdk-1 queue-id: 3 (enabled) pmd usage: 0 % > > > > > > port: vhu1d64ea7d-d9 queue-id: 0 (enabled) pmd usage: 0 % > > > > > > port: vhu1d64ea7d-d9 queue-id: 7 (enabled) pmd usage: 0 % > > > > > > port: vhu9c32faf6-ac queue-id: 0 (enabled) pmd usage: 0 % > > > > > > port: vhu9c32faf6-ac queue-id: 7 (enabled) pmd usage: 0 % > > > > > > pmd thread numa_id 0 core_id 33: > > > > > > isolated : false > > > > > > port: dpdk-1 queue-id: 2 (enabled) pmd usage: 0 % > > > > > > port: vhu1d64ea7d-d9 queue-id: 1 (enabled) pmd usage: 0 % > > > > > > port: vhu1d64ea7d-d9 queue-id: 6 (enabled) pmd usage: 0 % > > > > > > port: vhu9c32faf6-ac queue-id: 1 (enabled) pmd usage: 0 % > > > > > > port: vhu9c32faf6-ac queue-id: 6 (enabled) pmd usage: 0 % > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From stephenfin at redhat.com Mon Nov 30 14:45:52 2020 From: stephenfin at redhat.com (Stephen Finucane) Date: Mon, 30 Nov 2020 14:45:52 +0000 Subject: [ops][nova][designate] Does anyone rely on fully-qualified instance names? In-Reply-To: <20201130135830.q3fps4dwkxdiwngu@yuggoth.org> References: <20201130135830.q3fps4dwkxdiwngu@yuggoth.org> Message-ID: On Mon, 2020-11-30 at 13:58 +0000, Jeremy Stanley wrote: > On 2020-11-30 11:51:35 +0000 (+0000), Stephen Finucane wrote: > [...] > > This is more predictable but breaks the ability to use the > > instance name as a FQDN. Such usage is something I'm told we've > > never supported, but I'm concerned that there are users out there > > who are relying on this all the same and I'd like to get a feel > > for whether this is the case first. > > > > So, the question: does anyone currently rely on this inadvertent > > "feature"? > [...] > > Just to be clear because I'm not entirely sure I follow the > question: Are you asking whether users rely on being able to set > FQDNs as instance names? Or are you asking whether users rely on > Neutron setting those instance names automatically as DNS names? > > If it's the first, then yes lots of people (including my personal > servers, as well as all of the control plane infrastructure for the > OpenDev Collaboratory) enter the canonical DNS names of servers as > their instance names. We don't rely on any direct DNS integration in > our providers, but we do manually match instance names with address > records in the relevant DNS zones we maintain. The two questions are unfortunately intertwined. The same information - 'instance.hostname' - is used both by cloud-init (via the metadata service/config drive) to initialize the instance name [1] and by neutron when attaching ports on a network with DNS integration [2]. Unless we decouple those, any change will affect both. Stephen [1] https://github.com/openstack/nova/blob/16cabdd10/nova/api/metadata/base.py#L529-L535 [2] https://github.com/openstack/nova/blob/16cabdd10/nova/network/neutron.py#L1599-L1600 > This also came up in another bug report recently, by the way: > >     https://launchpad.net/bugs/1888722 > From rosmaita.fossdev at gmail.com Mon Nov 30 15:03:09 2020 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Mon, 30 Nov 2020 10:03:09 -0500 Subject: [cinder] Project ID in cinder endpoints and system scopes In-Reply-To: <5ded0a92-b6c0-8e58-667e-9184f2629f19@gandi.net> References: <5ded0a92-b6c0-8e58-667e-9184f2629f19@gandi.net> Message-ID: <197a1857-4719-9691-f486-118c77bfe699@gmail.com> From the cinder side of the bug, there are two things going on here. (1) There's an ambiguity in the term "endpoint": it could be (a) the base URL where the service can be contacted, or (b) the JSON "url" element that shows up in the "endpoints" list of a service object in the "catalog" list in the service catalog. In sense (a), a project_id does not occur in the Block Storage API endpoint. The Block Storage REST API, however, does require a project_id in most of the URLs it recognizes. Thinking of an "endpoint" in sense (a), these look like: where the parts are defined in the Block Storage API reference: https://docs.openstack.org/api-ref/block-storage/ When you look at the API reference, you'll see that for almost all calls, the Block Storage API requires a version indicator and project_id in the path. So if you leave these out, the service cannot resolve the URL and returns a 404. (2) Cinder doesn't support recognition of token scope in any released versions; we're working on it for Wallaby. (There's limited support in Victoria, but only for the default-types API.) cheers, brian On 11/30/20 4:35 AM, Nicolas Parquet wrote: > Hello there, > > Wondering if anyone has ongoing work or information on the following > bug: https://bugs.launchpad.net/keystone/+bug/1745905 > > We tried removing the project_id from cinder endpoints in order to test > system scopes and see if more is needed than oslo policy configuration, > but cannot get anything else than 404 responses. > > The bug description suggests it is just a documentation issue, but I > could not get a working setup. I also don't this mentioned in ptg > documentation regarding system scopes support. > > Any information or hint is welcome! > > Regards, > > -- > Nicolas Parquet > Gandi > nicolas.parquet at gandi.net > From smooney at redhat.com Mon Nov 30 15:16:08 2020 From: smooney at redhat.com (Sean Mooney) Date: Mon, 30 Nov 2020 15:16:08 +0000 Subject: [ops][nova][designate] Does anyone rely on fully-qualified instance names? In-Reply-To: <20201130135830.q3fps4dwkxdiwngu@yuggoth.org> References: <20201130135830.q3fps4dwkxdiwngu@yuggoth.org> Message-ID: On Mon, 2020-11-30 at 13:58 +0000, Jeremy Stanley wrote: > On 2020-11-30 11:51:35 +0000 (+0000), Stephen Finucane wrote: > [...] > > This is more predictable but breaks the ability to use the > > instance name as a FQDN. Such usage is something I'm told we've > > never supported, but I'm concerned that there are users out there > > who are relying on this all the same and I'd like to get a feel > > for whether this is the case first. > > > > So, the question: does anyone currently rely on this inadvertent > > "feature"? > [...] > > Just to be clear because I'm not entirely sure I follow the > question: Are you asking whether users rely on being able to set > FQDNs as instance names? Or are you asking whether users rely on > Neutron setting those instance names automatically as DNS names? yes stephen was asking whether users rely on being able to set > FQDNs as instance names > > If it's the first, then yes lots of people (including my personal > servers, as well as all of the control plane infrastructure for the > OpenDev Collaboratory) enter the canonical DNS names of servers as > their instance names. > so that has never actully been supported, the server name has to be a hostname not a FQDN. any use of a an fqdn has never been intended to be supproted. the fact it every worked is a result of incorerct sanitasation in the api which should have rejected it. the sanitisation code was orginally added to adress https://bugs.launchpad.net/nova/+bug/1495388 by try an munge server names into valid hostnames. https://github.com/openstack/nova/commit/bc6f30de953303604625e84ad2345cfb595170d2 we could extend it but if we really want to support FQDN that really feals like an new feature that would require an api microversion not a backportable bug fix. that bugfix is also not really correct '哈哈哈' which was the dislpayname that resulted in an empty host name is not invalid. https://tools.ietf.org/html/rfc5890 and the related docs which discirbes Internationalized Domain Names for Applications covers the use of unicode in domain names. granted back in 2014 our unicode support in openstack was not great but longterm we should allow internatalisted hostname that is out of scope of this converation however. wide use coudl temper that persepctive if suffince exising misuse of the api exists that we need to standarise that use. techinally you can set an fqdn in /etc/hostname but its discuraged  https://www.freedesktop.org/software/systemd/man/hostname.html " The hostname may be a free-form string up to 64 characters in length; however, it is recommended that it consists only of 7-bit ASCII lower-case characters and no spaces or dots, and limits itself to the format allowed for DNS domain name labels, even though this is not a strict requirement." https://www.freedesktop.org/wiki/Software/systemd/hostnamed/ " Generate a single DNS label only, not an FQDN. That means no dots allowed. Strip them, or replace them by "-". It's probably safer not to use any non-ASCII chars, even if DNS allows this in some way these days. In fact, restrict your charset to a-zA-Z0-9, - . Strip other chars, or try to replace them in some smart way with chars from this set, for example "ä" → "ae" and suchlike, and use "-" as replacement for all kinds of punctuation chars or spaces. Try to avoid creating repeated "-", as well as "-" as the first or last char. Limit the hostname to 63 chars, which is the length of a DNS label If after stripping special chars the empty string is the result, you can pass this as-is to hostnamed in which case it will automatically make "localhost" out of this. It probably is a good idea to replace uppercase by lowercase chars " if we are to munge the host server name to create the hostname the conventional approch woudl be striping '.' and replacing it with "-" if we choose to support FQDNs we need to ensure that any server name that is set as an FQDN is handeled explcitly and we do not add the dhcp_domain name to it when genreating the server metadata. we also proably need to strip the domain from it to have /etc/hostname correctly set to just the host name. converting the name to server- would work but it might be surprisign to some that expect the hostname in the server to match the server name which is why i prefer the 400 error for invalid input. regardless of what we choose however we should docuemtn this behavior as we dont document it at all. > We don't rely on any direct DNS integration in > our providers, but we do manually match instance names with address > records in the relevant DNS zones we maintain. > > This also came up in another bug report recently, by the way: > >     https://launchpad.net/bugs/1888722 > From satish.txt at gmail.com Mon Nov 30 15:26:10 2020 From: satish.txt at gmail.com (Satish Patel) Date: Mon, 30 Nov 2020 10:26:10 -0500 Subject: senlin SR-IOV instance support Message-ID: Folks, Does senlin support instance type SRIOV, I am successfully able to deploy using standard vm using virtio but for sriov instance we need to create a neutron port and then attach that port to VM. How does that process work with senlin? Currently I have the following profile: (if i want sriov instance then what i need to do?) type: os.nova.server version: 1.0 properties: name: cirros_server flavor: m1.small image: "cirros" key_name: ssh-key networks: - network: net1 metadata: test_key: test_value user_data: | #!/bin/sh echo 'hello, world' > /tmp/test_file ~S From fungi at yuggoth.org Mon Nov 30 15:36:33 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 30 Nov 2020 15:36:33 +0000 Subject: [ops][nova][designate] Does anyone rely on fully-qualified instance names? In-Reply-To: References: <20201130135830.q3fps4dwkxdiwngu@yuggoth.org> Message-ID: <20201130153632.rw3f47upjusodivw@yuggoth.org> On 2020-11-30 14:45:52 +0000 (+0000), Stephen Finucane wrote: [...] > The two questions are unfortunately intertwined. The same > information - 'instance.hostname' - is used both by cloud-init > (via the metadata service/config drive) to initialize the instance > name [1] and by neutron when attaching ports on a network with DNS > integration [2]. Unless we decouple those, any change will affect > both. [...] Okay, then there was also a hidden additional question in there. Do people who set DNS(-like) names for their server instance names also rely on the hostname reported in the instance metadata for configuring the guest OS? In our case we don't, we explicitly set up /etc/hosts and such with configuration management rather than trusting something like cloud-init to get it correct. In our case I don't think we particularly care what "hostname" gets reported in the metadata, only that the instance name remains flexible. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From whayutin at redhat.com Mon Nov 30 15:51:21 2020 From: whayutin at redhat.com (Wesley Hayutin) Date: Mon, 30 Nov 2020 08:51:21 -0700 Subject: [tripleo][ci] cm2 pip failures Message-ID: Greetings, FYI.. https://bugs.launchpad.net/tripleo/+bug/1906265 0/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensrloo at gmail.com Mon Nov 30 15:55:28 2020 From: opensrloo at gmail.com (Ruby Loo) Date: Mon, 30 Nov 2020 10:55:28 -0500 Subject: [ops][nova][designate] Does anyone rely on fully-qualified instance names? In-Reply-To: References: Message-ID: On Mon, Nov 30, 2020 at 6:56 AM Stephen Finucane wrote: > When attaching a port to an instance, nova will check for DNS support in > neutron > and set a 'dns_name' attribute if found. To populate this attribute, nova > uses a > sanitised version of the instance name, stored in the instance.hostname > attribute. This sanitisation simply strips out any unicode characters and > replaces underscores and spaces with dashes, before truncating to 63 > characters. > It does not currently replace periods and this is the cause of bug 1581977 > [1], > where an instance name such as 'ubuntu20.04' will fail to schedule since > neutron > identifies '04' as an invalid TLD. > > The question now is what to do to resolve this. There are two obvious paths > available to us. The first is to simply catch these invalid hostnames and > replace them with an arbitrary hostname of format 'Server-{serverUUID}'. > This is > what we currently do for purely unicode instance names and is what I've > proposed > at [2]. The other option is to strip all periods, or rather replace them > with > hyphens, when sanitizing the instance name. This is more predictable but > breaks > the ability to use the instance name as a FQDN. Such usage is something > I'm told > we've never supported, but I'm concerned that there are users out there > who are > relying on this all the same and I'd like to get a feel for whether this > is the > case first. > > So, the question: does anyone currently rely on this inadvertent "feature"? > I took a look and we (at Verizon Media) have users that create instances with fqdn-like names (VMs and BMs). I didn't look to see how many instances have such names, but we have tens of thousands of instances and eyeballing one of our clusters, > 90% of them have such names. --ruby > Cheers, > Stephen > > [1] https://launchpad.net/bugs/1581977 > [2] https://review.opendev.org/c/openstack/nova/+/764482 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at est.tech Mon Nov 30 16:16:51 2020 From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer) Date: Mon, 30 Nov 2020 17:16:51 +0100 Subject: [qa][all] pip 20.3 breaks jobs Message-ID: <3KAMKQ.IXCSM9FNMKU52@est.tech> Hi, Today pip 20.3 is released[1] and jobs started failing during keystone install in devstack with: 2020-11-30 15:14:31.117 | + inc/python:pip_install:193 : sudo -H LC_ALL=en_US.UTF-8 SETUPTOOLS_USE_DISTUTILS=stdlib http_proxy= https_proxy= no_proxy= PIP_FIND_LINKS= SETUPTOOLS_SYS_PATH_TECHNIQUE=rewrite python3.6 -m pip install -c /opt/stack/old/requirements/upper-constraints.txt -e /opt/stack/old/neutron 2020-11-30 15:14:32.271 | Looking in indexes: https://mirror.gra1.ovh.opendev.org/pypi/simple, https://mirror.gra1.ovh.opendev.org/wheel/ubuntu-18.04-x86_64 2020-11-30 15:14:32.272 | DEPRECATION: Constraints are only allowed to take the form of a package name and a version specifier. Other forms were originally permitted as an accident of the implementation, but were undocumented. The new implementation of the resolver no longer supports these forms. A possible replacement is replacing the constraint with a requirement.. You can find discussion regarding this at https://github.com/pypa/pip/issues/8210. 2020-11-30 15:14:32.272 | ERROR: Links are not allowed as constraints Logstash signature: [2] It seems not all the jobs are effected but at least grenade on master is hit [3]. It seems that passing jobs are using pip from the base image instead of installing a fresh one from pypi. As a first glance the change "Flip the switch on new resolver"[4] seem to be related. Cheers, gibi [1] https://pip.pypa.io/en/stable/news/#id1 [2] http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22Links%20are%20not%20allowed%20as%20constraints%5C%22 [3] https://zuul.opendev.org/t/openstack/builds?job_name=grenade&branch=master [4] https://github.com/pypa/pip/pull/9019 From neil at tigera.io Mon Nov 30 16:42:00 2020 From: neil at tigera.io (Neil Jerram) Date: Mon, 30 Nov 2020 16:42:00 +0000 Subject: [devstack][ussuri][keystone] ERROR: Links are not allowed as constraints Message-ID: With devstack pinned to stable/ussuri, on Ubuntu Bionic, stack.sh fails for me when it gets to the step of installing keystone: ... + lib/keystone:install_keystone:500 : setup_develop /opt/stack/keystone + inc/python:setup_develop:351 : local bindep + inc/python:setup_develop:352 : [[ /opt/stack/keystone == -bindep* ]] + inc/python:setup_develop:356 : local project_dir=/opt/stack/keystone + inc/python:setup_develop:357 : local extras= + inc/python:setup_develop:358 : _setup_package_with_constraints_edit /opt/stack/keystone -e + inc/python:_setup_package_with_constraints_edit:377 : local bindep + inc/python:_setup_package_with_constraints_edit:378 : [[ /opt/stack/keystone == -bindep* ]] + inc/python:_setup_package_with_constraints_edit:382 : local project_dir=/opt/stack/keystone + inc/python:_setup_package_with_constraints_edit:383 : local flags=-e + inc/python:_setup_package_with_constraints_edit:384 : local extras= ++ inc/python:_setup_package_with_constraints_edit:391 : cd /opt/stack/keystone ++ inc/python:_setup_package_with_constraints_edit:391 : pwd + inc/python:_setup_package_with_constraints_edit:391 : project_dir=/opt/stack/keystone + inc/python:_setup_package_with_constraints_edit:393 : '[' -n /opt/stack/requirements ']' + inc/python:_setup_package_with_constraints_edit:395 : local name ++ inc/python:_setup_package_with_constraints_edit:396 : awk '/^name.*=/ {print $3}' /opt/stack/keystone/setup.cfg + inc/python:_setup_package_with_constraints_edit:396 : name=keystone + inc/python:_setup_package_with_constraints_edit:398 : /opt/stack/requirements/.venv/bin/edit-constraints /opt/stack/requirements/upper-constraints.txt -- keystone '-e file:///opt/stack/keystone#egg=keystone' + inc/python:_setup_package_with_constraints_edit:402 : setup_package /opt/stack/keystone -e + inc/python:setup_package:430 : local bindep=0 + inc/python:setup_package:431 : local bindep_flag= + inc/python:setup_package:432 : local bindep_profiles= + inc/python:setup_package:433 : [[ /opt/stack/keystone == -bindep* ]] + inc/python:setup_package:438 : local project_dir=/opt/stack/keystone + inc/python:setup_package:439 : local flags=-e + inc/python:setup_package:440 : local extras= + inc/python:setup_package:444 : [[ -n -e ]] + inc/python:setup_package:444 : [[ -z '' ]] + inc/python:setup_package:444 : [[ ! -e =~ ^-.* ]] + inc/python:setup_package:449 : [[ ! -z '' ]] + inc/python:setup_package:454 : [[ 0 == 1 ]] + inc/python:setup_package:458 : pip_install -e /opt/stack/keystone Using python 3.6 to install /opt/stack/keystone because python3_enabled=True + inc/python:pip_install:200 : sudo -H LC_ALL=en_US.UTF-8 SETUPTOOLS_USE_DISTUTILS=stdlib http_proxy= https_proxy= no_proxy= PIP_FIND_LINKS= SETUPTOOLS_SYS_PATH_TECHNIQUE=rewrite /usr/local/bin/pip3.6 install -c /opt/stack/requirements/upper-constraints.txt -e /opt/stack/keystone WARNING: The directory '/home/semaphore/.pip_download_cache' or its parent directory is not owned or is not writable by the current user. The cache has been disabled. Check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag. DEPRECATION: Constraints are only allowed to take the form of a package name and a version specifier. Other forms were originally permitted as an accident of the implementation, but were undocumented. The new implementation of the resolver no longer supports these forms. A possible replacement is replacing the constraint with a requirement.. You can find discussion regarding this at https://github.com/pypa/pip/issues/8210. ERROR: Links are not allowed as constraints As far as I can work out, it's because install_keystone edits /opt/stack/requirements/upper-constraints.txt so that the line for keystone has "-e file:///opt/stack/keystone#egg=keystone", and pip then complains that file:// constraints are not supported. I'm sure there's a good reason but - as is often the case - I'm left wondering why this isn't broken for everyone! Any clues or suggestions gratefully received. Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From neil at tigera.io Mon Nov 30 16:43:47 2020 From: neil at tigera.io (Neil Jerram) Date: Mon, 30 Nov 2020 16:43:47 +0000 Subject: [qa][all] pip 20.3 breaks jobs In-Reply-To: <3KAMKQ.IXCSM9FNMKU52@est.tech> References: <3KAMKQ.IXCSM9FNMKU52@est.tech> Message-ID: On Mon, Nov 30, 2020 at 4:18 PM Balázs Gibizer wrote: > Hi, > > Today pip 20.3 is released[1] and jobs started failing during keystone > install in devstack with: > > 2020-11-30 15:14:31.117 | + inc/python:pip_install:193 : > sudo -H LC_ALL=en_US.UTF-8 SETUPTOOLS_USE_DISTUTILS=stdlib http_proxy= > https_proxy= no_proxy= PIP_FIND_LINKS= > SETUPTOOLS_SYS_PATH_TECHNIQUE=rewrite python3.6 -m pip install -c > /opt/stack/old/requirements/upper-constraints.txt -e > /opt/stack/old/neutron > 2020-11-30 15:14:32.271 | Looking in indexes: > https://mirror.gra1.ovh.opendev.org/pypi/simple, > https://mirror.gra1.ovh.opendev.org/wheel/ubuntu-18.04-x86_64 > 2020-11-30 15:14:32.272 | DEPRECATION: Constraints are only allowed to > take the form of a package name and a version specifier. Other forms > were originally permitted as an accident of the implementation, but > were undocumented. The new implementation of the resolver no longer > supports these forms. A possible replacement is replacing the > constraint with a requirement.. You can find discussion regarding this > at https://github.com/pypa/pip/issues/8210. > 2020-11-30 15:14:32.272 | ERROR: Links are not allowed as constraints > Ah, snap! I just started another thread about this; sorry for not seeing your thread first. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Mon Nov 30 16:50:39 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 30 Nov 2020 16:50:39 +0000 Subject: [ops][nova][designate] Does anyone rely on fully-qualified instance names? In-Reply-To: References: <20201130135830.q3fps4dwkxdiwngu@yuggoth.org> Message-ID: <20201130165039.gebc7aaxm4tw3czu@yuggoth.org> On 2020-11-30 15:16:08 +0000 (+0000), Sean Mooney wrote: [...] > so that has never actully been supported, the server name has to > be a hostname not a FQDN. any use of a an fqdn has never been > intended to be supproted. [...] > techinally you can set an fqdn in /etc/hostname but its discuraged  [...] Yes, we directly set /etc/hostname to contain the "short" hostname and set the FQDN in /etc/hosts as an alias for it bound to a (secondary) v4 loopback consistent with the default configurations for Debian/Ubuntu systems. We don't rely on hostname metadata or cloud-init to provide correct representations, as cloud providers like to mess around with things like default domains and that leads to an inconsistent experience across different environments. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From fungi at yuggoth.org Mon Nov 30 16:55:12 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 30 Nov 2020 16:55:12 +0000 Subject: [tripleo][ci] cm2 pip failures In-Reply-To: References: Message-ID: <20201130165512.omzmoiyrk2o5ohyo@yuggoth.org> On 2020-11-30 08:51:21 -0700 (-0700), Wesley Hayutin wrote: > FYI.. > https://bugs.launchpad.net/tripleo/+bug/1906265 I've updated the bug as well, but this may be useful information for other projects too: Be aware that pip 20.3 was uploaded to PyPI roughly 4 hours ago, and is the first release to enable the new dependency solver, so you may want to check whether this is reproducible with earlier pip. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From duc.openstack at gmail.com Mon Nov 30 17:11:20 2020 From: duc.openstack at gmail.com (Duc Truong) Date: Mon, 30 Nov 2020 09:11:20 -0800 Subject: senlin SR-IOV instance support In-Reply-To: References: Message-ID: I discussed several options for this with Satish in the Senlin IRC channel: http://eavesdrop.openstack.org/irclogs/%23senlin/%23senlin.2020-11-30.log.html On Mon, Nov 30, 2020 at 7:26 AM Satish Patel wrote: > > Folks, > > Does senlin support instance type SRIOV, I am successfully able to > deploy using standard vm using virtio but for sriov instance we need > to create a neutron port and then attach that port to VM. How does > that process work with senlin? > > Currently I have the following profile: (if i want sriov instance then > what i need to do?) > > type: os.nova.server > version: 1.0 > properties: > name: cirros_server > flavor: m1.small > image: "cirros" > key_name: ssh-key > networks: > - network: net1 > metadata: > test_key: test_value > user_data: | > #!/bin/sh > echo 'hello, world' > /tmp/test_file > > > ~S > From satish.txt at gmail.com Mon Nov 30 17:31:27 2020 From: satish.txt at gmail.com (Satish Patel) Date: Mon, 30 Nov 2020 12:31:27 -0500 Subject: senlin SR-IOV instance support In-Reply-To: References: Message-ID: Thank Duc, I am going to work on it and see how we can add that SR-IOV feature to the senlin profile. On Mon, Nov 30, 2020 at 12:11 PM Duc Truong wrote: > > I discussed several options for this with Satish in the Senlin IRC channel: > http://eavesdrop.openstack.org/irclogs/%23senlin/%23senlin.2020-11-30.log.html > > On Mon, Nov 30, 2020 at 7:26 AM Satish Patel wrote: > > > > Folks, > > > > Does senlin support instance type SRIOV, I am successfully able to > > deploy using standard vm using virtio but for sriov instance we need > > to create a neutron port and then attach that port to VM. How does > > that process work with senlin? > > > > Currently I have the following profile: (if i want sriov instance then > > what i need to do?) > > > > type: os.nova.server > > version: 1.0 > > properties: > > name: cirros_server > > flavor: m1.small > > image: "cirros" > > key_name: ssh-key > > networks: > > - network: net1 > > metadata: > > test_key: test_value > > user_data: | > > #!/bin/sh > > echo 'hello, world' > /tmp/test_file > > > > > > ~S > > From johnsomor at gmail.com Mon Nov 30 18:13:00 2020 From: johnsomor at gmail.com (Michael Johnson) Date: Mon, 30 Nov 2020 10:13:00 -0800 Subject: [ops][nova][designate] Does anyone rely on fully-qualified instance names? In-Reply-To: <20201130165039.gebc7aaxm4tw3czu@yuggoth.org> References: <20201130135830.q3fps4dwkxdiwngu@yuggoth.org> <20201130165039.gebc7aaxm4tw3czu@yuggoth.org> Message-ID: I think we should align to the RFCs. First thing to note is hostnames do not have the same rules as domain names. For terminology purposes, I will use the RFC terminology: . RFC 952 [1] and RFC 1123 [2] define the valid strings for a hostname. A short summary is alphabet (A-Z), digits (0-9), minus sign (-) up to 255 characters. Internationalized hostnames are converted to these rules using Punycode [3]. This is also true for domain names. One of the most common differences between hostnames and domain names is underscores. Underscore is invalid in a hostname, but valid in a domain name. So, I think I am in alignment with Sean. The hostname component should return a 400 if there is an illegal character in the string, such as a period. We also should use Punycode to store/handle unicode hostnames correctly. Michael [1] https://tools.ietf.org/html/rfc952 [2] https://tools.ietf.org/html/rfc1123#page-13 [3] https://www.rfc-editor.org/rfc/rfc3492.txt On Mon, Nov 30, 2020 at 8:54 AM Jeremy Stanley wrote: > > On 2020-11-30 15:16:08 +0000 (+0000), Sean Mooney wrote: > [...] > > so that has never actully been supported, the server name has to > > be a hostname not a FQDN. any use of a an fqdn has never been > > intended to be supproted. > [...] > > techinally you can set an fqdn in /etc/hostname but its discuraged > [...] > > Yes, we directly set /etc/hostname to contain the "short" hostname > and set the FQDN in /etc/hosts as an alias for it bound to a > (secondary) v4 loopback consistent with the default configurations > for Debian/Ubuntu systems. We don't rely on hostname metadata or > cloud-init to provide correct representations, as cloud providers > like to mess around with things like default domains and that leads > to an inconsistent experience across different environments. > -- > Jeremy Stanley From fungi at yuggoth.org Mon Nov 30 18:16:56 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 30 Nov 2020 18:16:56 +0000 Subject: [ops][nova][designate] Does anyone rely on fully-qualified instance names? In-Reply-To: References: <20201130135830.q3fps4dwkxdiwngu@yuggoth.org> <20201130165039.gebc7aaxm4tw3czu@yuggoth.org> Message-ID: <20201130181655.tyzvbvizfbokw72q@yuggoth.org> On 2020-11-30 10:13:00 -0800 (-0800), Michael Johnson wrote: [...] > So, I think I am in alignment with Sean. The hostname component should > return a 400 if there is an illegal character in the string, such as a > period. We also should use Punycode to store/handle unicode hostnames > correctly. [...] So to be clear, you're suggesting that if someone asks for an instance name which can't be converted to a (legal) hostname, then the nova boot call be rejected outright, even though there are likely plenty of people who 1. (manually) align their instance names with FQDNs, and 2. don't use the hostname metadata anyway? -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From smooney at redhat.com Mon Nov 30 18:49:04 2020 From: smooney at redhat.com (Sean Mooney) Date: Mon, 30 Nov 2020 18:49:04 +0000 Subject: [ops][nova][designate] Does anyone rely on fully-qualified instance names? In-Reply-To: References: Message-ID: <10e014daa6f59cfc3c2c8ed6271077df8d3b3d66.camel@redhat.com> On Mon, 2020-11-30 at 10:55 -0500, Ruby Loo wrote: > On Mon, Nov 30, 2020 at 6:56 AM Stephen Finucane > wrote: > > > When attaching a port to an instance, nova will check for DNS support in > > neutron > > and set a 'dns_name' attribute if found. To populate this attribute, nova > > uses a > > sanitised version of the instance name, stored in the instance.hostname > > attribute. This sanitisation simply strips out any unicode characters and > > replaces underscores and spaces with dashes, before truncating to 63 > > characters. > > It does not currently replace periods and this is the cause of bug 1581977 > > [1], > > where an instance name such as 'ubuntu20.04' will fail to schedule since > > neutron > > identifies '04' as an invalid TLD. > > > > The question now is what to do to resolve this. There are two obvious paths > > available to us. The first is to simply catch these invalid hostnames and > > replace them with an arbitrary hostname of format 'Server-{serverUUID}'. > > This is > > what we currently do for purely unicode instance names and is what I've > > proposed > > at [2]. The other option is to strip all periods, or rather replace them > > with > > hyphens, when sanitizing the instance name. This is more predictable but > > breaks > > the ability to use the instance name as a FQDN. Such usage is something > > I'm told > > we've never supported, but I'm concerned that there are users out there > > who are > > relying on this all the same and I'd like to get a feel for whether this > > is the > > case first. > > > > So, the question: does anyone currently rely on this inadvertent "feature"? > > > >  I took a look and we (at Verizon Media) have users that create instances > with fqdn-like names (VMs and BMs). I didn't look to see how many instances > have such names, but we have tens of thousands of instances and eyeballing > one of our clusters, > 90% of them have such names. ok based on this we cant outright block fqdns in teh api. their use is still undefined but we at least need to provide a deprecation cycle and upgrade procedure it we want to remove them though it sound like we need to actully add support which mean we need to agree on the semantics. i have done some testing with designate enabled and use fqdns http://paste.openstack.org/show/800564/ tl;dr its totally inconsitent and broken in various way but you can boot vmand networking appears to work. i booted a server wtih the server name test-dns.invalid.dns the default domain name for my deploymnent in designate is cloud.seanmooney.info the hostname in the vm is test-dns ubuntu at test-dns:~$ cat /etc/hostname test-dns ubuntu at test-dns:~$ hostname test-dns however the fqdn is reported as test-dns.cloud.seanmooney.info ubuntu at test-dns:~$ hostname -f test-dns.cloud.seanmooney.info if we list all fqdns we get ubuntu at test-dns:~$ hostname -A test-dns.invalid.dns.cloud.seanmooney.info test-dns.invalid.dns.cloud.seanmooney.info not that it appends the default designate domain to the server name looking at the ec2 metadata the server name is appended to the nova dhcp_domain conf option value "hostname": "test-dns.invalid.dns.novalocal", "instance-action": "none", "instance-id": "i-00000109", "instance-type": "small-multi-numa", "local-hostname": "test-dns.invalid.dns.novalocal", "local-ipv4": "172.20.4.32", "placement": { "availability-zone": "nova" }, "public-hostname": "test-dns.invalid.dns.novalocal", and the openstack varient is "local-hostname": "test-dns", so the server has 4 posible hostnames and none of them are server name "test-dns.invalid.dns" test-dns.invalid.dns does resolve on the host buntu at test-dns:~$ ping test-dns.invalid.dns PING test-dns.invalid.dns(test-dns.invalid.dns.cloud.seanmooney.info (2001:470:1836:1:f816:3eff:fe59:f619)) 56 data bytes 64 bytes from test-dns.invalid.dns.cloud.seanmooney.info (2001:470:1836:1:f816:3eff:fe59:f619): icmp_seq=1 ttl=64 time=0.039 ms 64 bytes from test-dns.invalid.dns.cloud.seanmooney.info (2001:470:1836:1:f816:3eff:fe59:f619): icmp_seq=2 ttl=64 time=0.062 ms ^C --- test-dns.invalid.dns ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 0.039/0.050/0.062/0.011 ms ubuntu at test-dns:~$ nslookup test-dns.invalid.dns Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: test-dns.invalid.dns Address: 172.20.4.32 Name: test-dns.invalid.dns Address: 2001:470:1836:1:f816:3eff:fe59:f619 but only because of the dns search path ubuntu at test-dns:~$ cat /etc/resolv.conf # This file is managed by man:systemd-resolved(8). Do not edit. # # This is a dynamic resolv.conf file for connecting local clients to the # internal DNS stub resolver of systemd-resolved. This file lists all # configured search domains. # # Run "resolvectl status" to see details about the uplink DNS servers # currently in use. # # Third party programs must not access this file directly, but only through the # symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way, # replace this symlink by a static file or a different symlink. # # See man:systemd-resolved.service(8) for details about the supported modes of # operation for /etc/resolv.conf. nameserver 127.0.0.53 options edns0 search cloud.seanmooney.info ubuntu at test-dns:~$ systemd-resolve --status Global LLMNR setting: no MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no DNSSEC NTA: 10.in-addr.arpa 16.172.in-addr.arpa 168.192.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa corp d.f.ip6.arpa home internal intranet lan local private test Link 2 (enp1s0) Current Scopes: DNS DefaultRoute setting: yes LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no Current DNS Server: 172.20.4.2 DNS Servers: 172.20.4.2 2001:470:1836:1:f816:3eff:fe7b:583 DNS Domain: cloud.seanmooney.info  as far as i can tell there is no file or data source that will allow you to see teh server name value test-dns.invalid.dns the closest you can get is the instance uuid 9387d654-93eb-41cf-9f59-a6099e0daba1 in the cloud metadata. so i you are using FQDNs today it does not work in any useful way. > > --ruby > > > > Cheers, > > Stephen > > > > [1] https://launchpad.net/bugs/1581977 > > [2] https://review.opendev.org/c/openstack/nova/+/764482 > > > > > > From johnsomor at gmail.com Mon Nov 30 19:17:14 2020 From: johnsomor at gmail.com (Michael Johnson) Date: Mon, 30 Nov 2020 11:17:14 -0800 Subject: [ops][nova][designate] Does anyone rely on fully-qualified instance names? In-Reply-To: <10e014daa6f59cfc3c2c8ed6271077df8d3b3d66.camel@redhat.com> References: <10e014daa6f59cfc3c2c8ed6271077df8d3b3d66.camel@redhat.com> Message-ID: If we are going to continue to use the "name" API field to populate metadata for the instance and set the dns_name field of the port, yes. Really the right answer is to add a hostname field to the nova API that had the proper validation and IDN support. That way the "name" field is simple API metadata and not overloaded for multiple purposes. Michael On Mon, Nov 30, 2020 at 10:52 AM Sean Mooney wrote: > > On Mon, 2020-11-30 at 10:55 -0500, Ruby Loo wrote: > > On Mon, Nov 30, 2020 at 6:56 AM Stephen Finucane > > wrote: > > > > > When attaching a port to an instance, nova will check for DNS support in > > > neutron > > > and set a 'dns_name' attribute if found. To populate this attribute, nova > > > uses a > > > sanitised version of the instance name, stored in the instance.hostname > > > attribute. This sanitisation simply strips out any unicode characters and > > > replaces underscores and spaces with dashes, before truncating to 63 > > > characters. > > > It does not currently replace periods and this is the cause of bug 1581977 > > > [1], > > > where an instance name such as 'ubuntu20.04' will fail to schedule since > > > neutron > > > identifies '04' as an invalid TLD. > > > > > > The question now is what to do to resolve this. There are two obvious paths > > > available to us. The first is to simply catch these invalid hostnames and > > > replace them with an arbitrary hostname of format 'Server-{serverUUID}'. > > > This is > > > what we currently do for purely unicode instance names and is what I've > > > proposed > > > at [2]. The other option is to strip all periods, or rather replace them > > > with > > > hyphens, when sanitizing the instance name. This is more predictable but > > > breaks > > > the ability to use the instance name as a FQDN. Such usage is something > > > I'm told > > > we've never supported, but I'm concerned that there are users out there > > > who are > > > relying on this all the same and I'd like to get a feel for whether this > > > is the > > > case first. > > > > > > So, the question: does anyone currently rely on this inadvertent "feature"? > > > > > > > I took a look and we (at Verizon Media) have users that create instances > > with fqdn-like names (VMs and BMs). I didn't look to see how many instances > > have such names, but we have tens of thousands of instances and eyeballing > > one of our clusters, > 90% of them have such names. > > ok based on this we cant outright block fqdns in teh api. > their use is still undefined but we at least need to provide a deprecation cycle and upgrade procedure > it we want to remove them though it sound like we need to actully add support which mean we need to agree on the semantics. > > > i have done some testing with designate enabled and use fqdns > > http://paste.openstack.org/show/800564/ > > tl;dr its totally inconsitent and broken in various way but you can boot vmand networking appears to work. > > i booted a server wtih the server name test-dns.invalid.dns > the default domain name for my deploymnent in designate is cloud.seanmooney.info > > > the hostname in the vm is test-dns > > ubuntu at test-dns:~$ cat /etc/hostname > test-dns > > ubuntu at test-dns:~$ hostname > test-dns > > however the fqdn is reported as test-dns.cloud.seanmooney.info > > ubuntu at test-dns:~$ hostname -f > test-dns.cloud.seanmooney.info > > if we list all fqdns we get > ubuntu at test-dns:~$ hostname -A > test-dns.invalid.dns.cloud.seanmooney.info test-dns.invalid.dns.cloud.seanmooney.info > not that it appends the default designate domain to the server name > > looking at the ec2 metadata the server name is appended to the nova dhcp_domain conf option value > > "hostname": "test-dns.invalid.dns.novalocal", > "instance-action": "none", > "instance-id": "i-00000109", > "instance-type": "small-multi-numa", > "local-hostname": "test-dns.invalid.dns.novalocal", > "local-ipv4": "172.20.4.32", > "placement": { > "availability-zone": "nova" > }, > "public-hostname": "test-dns.invalid.dns.novalocal", > > > and the openstack varient is > "local-hostname": "test-dns", > > so the server has 4 posible hostnames and none of them are server name "test-dns.invalid.dns" > > test-dns.invalid.dns does resolve on the host > > buntu at test-dns:~$ ping test-dns.invalid.dns > PING test-dns.invalid.dns(test-dns.invalid.dns.cloud.seanmooney.info (2001:470:1836:1:f816:3eff:fe59:f619)) 56 data bytes > 64 bytes from test-dns.invalid.dns.cloud.seanmooney.info (2001:470:1836:1:f816:3eff:fe59:f619): icmp_seq=1 ttl=64 time=0.039 ms > 64 bytes from test-dns.invalid.dns.cloud.seanmooney.info (2001:470:1836:1:f816:3eff:fe59:f619): icmp_seq=2 ttl=64 time=0.062 ms > ^C > --- test-dns.invalid.dns ping statistics --- > 2 packets transmitted, 2 received, 0% packet loss, time 1001ms > rtt min/avg/max/mdev = 0.039/0.050/0.062/0.011 ms > ubuntu at test-dns:~$ nslookup test-dns.invalid.dns > Server: 127.0.0.53 > Address: 127.0.0.53#53 > > Non-authoritative answer: > Name: test-dns.invalid.dns > Address: 172.20.4.32 > Name: test-dns.invalid.dns > Address: 2001:470:1836:1:f816:3eff:fe59:f619 > > > but only because of the dns search path > > > ubuntu at test-dns:~$ cat /etc/resolv.conf > # This file is managed by man:systemd-resolved(8). Do not edit. > # > # This is a dynamic resolv.conf file for connecting local clients to the > # internal DNS stub resolver of systemd-resolved. This file lists all > # configured search domains. > # > # Run "resolvectl status" to see details about the uplink DNS servers > # currently in use. > # > # Third party programs must not access this file directly, but only through the > # symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way, > # replace this symlink by a static file or a different symlink. > # > # See man:systemd-resolved.service(8) for details about the supported modes of > # operation for /etc/resolv.conf. > > nameserver 127.0.0.53 > options edns0 > search cloud.seanmooney.info > > ubuntu at test-dns:~$ systemd-resolve --status > Global > LLMNR setting: no > MulticastDNS setting: no > DNSOverTLS setting: no > DNSSEC setting: no > DNSSEC supported: no > DNSSEC NTA: 10.in-addr.arpa > 16.172.in-addr.arpa > 168.192.in-addr.arpa > 17.172.in-addr.arpa > 18.172.in-addr.arpa > 19.172.in-addr.arpa > 20.172.in-addr.arpa > 21.172.in-addr.arpa > 22.172.in-addr.arpa > 23.172.in-addr.arpa > 24.172.in-addr.arpa > 25.172.in-addr.arpa > 26.172.in-addr.arpa > 27.172.in-addr.arpa > 28.172.in-addr.arpa > 29.172.in-addr.arpa > 30.172.in-addr.arpa > 31.172.in-addr.arpa > corp > d.f.ip6.arpa > home > internal > intranet > lan > local > private > test > > Link 2 (enp1s0) > Current Scopes: DNS > DefaultRoute setting: yes > LLMNR setting: yes > MulticastDNS setting: no > DNSOverTLS setting: no > DNSSEC setting: no > DNSSEC supported: no > Current DNS Server: 172.20.4.2 > DNS Servers: 172.20.4.2 > 2001:470:1836:1:f816:3eff:fe7b:583 > DNS Domain: cloud.seanmooney.info > > > as far as i can tell there is no file or data source that will allow you to see teh server name value > test-dns.invalid.dns the closest you can get is the instance uuid 9387d654-93eb-41cf-9f59-a6099e0daba1 in the cloud metadata. > > so i you are using FQDNs today it does not work in any useful way. > > > > > --ruby > > > > > > > Cheers, > > > Stephen > > > > > > [1] https://launchpad.net/bugs/1581977 > > > [2] https://review.opendev.org/c/openstack/nova/+/764482 > > > > > > > > > > > > From alifshit at redhat.com Mon Nov 30 19:35:54 2020 From: alifshit at redhat.com (Artom Lifshitz) Date: Mon, 30 Nov 2020 14:35:54 -0500 Subject: [ops][nova][designate] Does anyone rely on fully-qualified instance names? In-Reply-To: References: <10e014daa6f59cfc3c2c8ed6271077df8d3b3d66.camel@redhat.com> Message-ID: On Mon, Nov 30, 2020 at 2:20 PM Michael Johnson wrote: > > If we are going to continue to use the "name" API field to populate > metadata for the instance and set the dns_name field of the port, yes. > > Really the right answer is to add a hostname field to the nova API > that had the proper validation and IDN support. That way the "name" > field is simple API metadata and not overloaded for multiple purposes. Yeah, I don't think anyone's going to disagree with this. But this would be a new microversion, and so cannot be backported to stable releases. Our (RedHat's) pickle is what to do in the case of someone wanting to use domain-like VM names with Neutron DNS integration. Currently what ends up in Neutron's dns_name field (and in Nova's instance.hostname) is derived from the VM name, but that derivation allows things that Neutron doesn't agree are valid - namely, endings in .. I think Stephen's original question is around modifying how we do that derivation, and whether starting to transform . into Server- would break anyone. My proposal would be to just guard that new transformation with a [workarounds] config option. I know it's lazy and dirty, but as you pointed out, the real solution is a new API microversion that splits the VM display name from the hostname/FQDN entirely. The new [workarounds] option means anyone hitting bug 1581977 can turn it on fully aware of what's going to happen (namely, ubuntu.04 getting a hostname of Server-), and anyone not affected can carry on as before. > > Michael > > On Mon, Nov 30, 2020 at 10:52 AM Sean Mooney wrote: > > > > On Mon, 2020-11-30 at 10:55 -0500, Ruby Loo wrote: > > > On Mon, Nov 30, 2020 at 6:56 AM Stephen Finucane > > > wrote: > > > > > > > When attaching a port to an instance, nova will check for DNS support in > > > > neutron > > > > and set a 'dns_name' attribute if found. To populate this attribute, nova > > > > uses a > > > > sanitised version of the instance name, stored in the instance.hostname > > > > attribute. This sanitisation simply strips out any unicode characters and > > > > replaces underscores and spaces with dashes, before truncating to 63 > > > > characters. > > > > It does not currently replace periods and this is the cause of bug 1581977 > > > > [1], > > > > where an instance name such as 'ubuntu20.04' will fail to schedule since > > > > neutron > > > > identifies '04' as an invalid TLD. > > > > > > > > The question now is what to do to resolve this. There are two obvious paths > > > > available to us. The first is to simply catch these invalid hostnames and > > > > replace them with an arbitrary hostname of format 'Server-{serverUUID}'. > > > > This is > > > > what we currently do for purely unicode instance names and is what I've > > > > proposed > > > > at [2]. The other option is to strip all periods, or rather replace them > > > > with > > > > hyphens, when sanitizing the instance name. This is more predictable but > > > > breaks > > > > the ability to use the instance name as a FQDN. Such usage is something > > > > I'm told > > > > we've never supported, but I'm concerned that there are users out there > > > > who are > > > > relying on this all the same and I'd like to get a feel for whether this > > > > is the > > > > case first. > > > > > > > > So, the question: does anyone currently rely on this inadvertent "feature"? > > > > > > > > > > I took a look and we (at Verizon Media) have users that create instances > > > with fqdn-like names (VMs and BMs). I didn't look to see how many instances > > > have such names, but we have tens of thousands of instances and eyeballing > > > one of our clusters, > 90% of them have such names. > > > > ok based on this we cant outright block fqdns in teh api. > > their use is still undefined but we at least need to provide a deprecation cycle and upgrade procedure > > it we want to remove them though it sound like we need to actully add support which mean we need to agree on the semantics. > > > > > > i have done some testing with designate enabled and use fqdns > > > > http://paste.openstack.org/show/800564/ > > > > tl;dr its totally inconsitent and broken in various way but you can boot vmand networking appears to work. > > > > i booted a server wtih the server name test-dns.invalid.dns > > the default domain name for my deploymnent in designate is cloud.seanmooney.info > > > > > > the hostname in the vm is test-dns > > > > ubuntu at test-dns:~$ cat /etc/hostname > > test-dns > > > > ubuntu at test-dns:~$ hostname > > test-dns > > > > however the fqdn is reported as test-dns.cloud.seanmooney.info > > > > ubuntu at test-dns:~$ hostname -f > > test-dns.cloud.seanmooney.info > > > > if we list all fqdns we get > > ubuntu at test-dns:~$ hostname -A > > test-dns.invalid.dns.cloud.seanmooney.info test-dns.invalid.dns.cloud.seanmooney.info > > not that it appends the default designate domain to the server name > > > > looking at the ec2 metadata the server name is appended to the nova dhcp_domain conf option value > > > > "hostname": "test-dns.invalid.dns.novalocal", > > "instance-action": "none", > > "instance-id": "i-00000109", > > "instance-type": "small-multi-numa", > > "local-hostname": "test-dns.invalid.dns.novalocal", > > "local-ipv4": "172.20.4.32", > > "placement": { > > "availability-zone": "nova" > > }, > > "public-hostname": "test-dns.invalid.dns.novalocal", > > > > > > and the openstack varient is > > "local-hostname": "test-dns", > > > > so the server has 4 posible hostnames and none of them are server name "test-dns.invalid.dns" > > > > test-dns.invalid.dns does resolve on the host > > > > buntu at test-dns:~$ ping test-dns.invalid.dns > > PING test-dns.invalid.dns(test-dns.invalid.dns.cloud.seanmooney.info (2001:470:1836:1:f816:3eff:fe59:f619)) 56 data bytes > > 64 bytes from test-dns.invalid.dns.cloud.seanmooney.info (2001:470:1836:1:f816:3eff:fe59:f619): icmp_seq=1 ttl=64 time=0.039 ms > > 64 bytes from test-dns.invalid.dns.cloud.seanmooney.info (2001:470:1836:1:f816:3eff:fe59:f619): icmp_seq=2 ttl=64 time=0.062 ms > > ^C > > --- test-dns.invalid.dns ping statistics --- > > 2 packets transmitted, 2 received, 0% packet loss, time 1001ms > > rtt min/avg/max/mdev = 0.039/0.050/0.062/0.011 ms > > ubuntu at test-dns:~$ nslookup test-dns.invalid.dns > > Server: 127.0.0.53 > > Address: 127.0.0.53#53 > > > > Non-authoritative answer: > > Name: test-dns.invalid.dns > > Address: 172.20.4.32 > > Name: test-dns.invalid.dns > > Address: 2001:470:1836:1:f816:3eff:fe59:f619 > > > > > > but only because of the dns search path > > > > > > ubuntu at test-dns:~$ cat /etc/resolv.conf > > # This file is managed by man:systemd-resolved(8). Do not edit. > > # > > # This is a dynamic resolv.conf file for connecting local clients to the > > # internal DNS stub resolver of systemd-resolved. This file lists all > > # configured search domains. > > # > > # Run "resolvectl status" to see details about the uplink DNS servers > > # currently in use. > > # > > # Third party programs must not access this file directly, but only through the > > # symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way, > > # replace this symlink by a static file or a different symlink. > > # > > # See man:systemd-resolved.service(8) for details about the supported modes of > > # operation for /etc/resolv.conf. > > > > nameserver 127.0.0.53 > > options edns0 > > search cloud.seanmooney.info > > > > ubuntu at test-dns:~$ systemd-resolve --status > > Global > > LLMNR setting: no > > MulticastDNS setting: no > > DNSOverTLS setting: no > > DNSSEC setting: no > > DNSSEC supported: no > > DNSSEC NTA: 10.in-addr.arpa > > 16.172.in-addr.arpa > > 168.192.in-addr.arpa > > 17.172.in-addr.arpa > > 18.172.in-addr.arpa > > 19.172.in-addr.arpa > > 20.172.in-addr.arpa > > 21.172.in-addr.arpa > > 22.172.in-addr.arpa > > 23.172.in-addr.arpa > > 24.172.in-addr.arpa > > 25.172.in-addr.arpa > > 26.172.in-addr.arpa > > 27.172.in-addr.arpa > > 28.172.in-addr.arpa > > 29.172.in-addr.arpa > > 30.172.in-addr.arpa > > 31.172.in-addr.arpa > > corp > > d.f.ip6.arpa > > home > > internal > > intranet > > lan > > local > > private > > test > > > > Link 2 (enp1s0) > > Current Scopes: DNS > > DefaultRoute setting: yes > > LLMNR setting: yes > > MulticastDNS setting: no > > DNSOverTLS setting: no > > DNSSEC setting: no > > DNSSEC supported: no > > Current DNS Server: 172.20.4.2 > > DNS Servers: 172.20.4.2 > > 2001:470:1836:1:f816:3eff:fe7b:583 > > DNS Domain: cloud.seanmooney.info > > > > > > as far as i can tell there is no file or data source that will allow you to see teh server name value > > test-dns.invalid.dns the closest you can get is the instance uuid 9387d654-93eb-41cf-9f59-a6099e0daba1 in the cloud metadata. > > > > so i you are using FQDNs today it does not work in any useful way. > > > > > > > > --ruby > > > > > > > > > > Cheers, > > > > Stephen > > > > > > > > [1] https://launchpad.net/bugs/1581977 > > > > [2] https://review.opendev.org/c/openstack/nova/+/764482 > > > > > > > > > > > > > > > > > > > From smooney at redhat.com Mon Nov 30 19:50:22 2020 From: smooney at redhat.com (Sean Mooney) Date: Mon, 30 Nov 2020 19:50:22 +0000 Subject: [ops][nova][designate] Does anyone rely on fully-qualified instance names? In-Reply-To: <20201130181655.tyzvbvizfbokw72q@yuggoth.org> References: <20201130135830.q3fps4dwkxdiwngu@yuggoth.org> <20201130165039.gebc7aaxm4tw3czu@yuggoth.org> <20201130181655.tyzvbvizfbokw72q@yuggoth.org> Message-ID: On Mon, 2020-11-30 at 18:16 +0000, Jeremy Stanley wrote: > On 2020-11-30 10:13:00 -0800 (-0800), Michael Johnson wrote: > [...] > > So, I think I am in alignment with Sean. The hostname component should > > return a 400 if there is an illegal character in the string, such as a > > period. We also should use Punycode to store/handle unicode hostnames > > correctly. > [...] > > So to be clear, you're suggesting that if someone asks for an > instance name which can't be converted to a (legal) hostname, then > the nova boot call be rejected outright, even though there are > likely plenty of people who 1. (manually) align their instance names > with FQDNs, and 2. don't use the hostname metadata anyway? unfortunetly we cant do that even if its the right thing to do technically. i think the path forward has to be something more like this. 1.) add a new workaround config option e.g. disable_strict_server_name_check. for upgrade reason it would default to true in wallaby when strict server name checking is disabled we will transform any malformed numeric tld by replacing the '.' with '-' or by replacing the hostname with server- as we do with unicode hostnames. 2.) add a new api micro versions and do one of: a.) reject servers with invlaid server names that contain '.' with a 400 b.) transform server names according to the RFEs (replace all '.' and other disallowed charaters with -) c.) add support for FQDNs to the api. this coudl be something like adding a new field to store the fqdn as a top level filed on the server. make hostname contain jsut the host name with the full FQDN in the new fqdn field. if the server name is an fqdn the the fqdn field would just be the server name. if the server name is the a hostname then the nova dhcp_domain will be appended to servername this will allow the remvoal of dhcp_domain from the compute node for config driver generateion and we can generate the metadat form teh new fqdn filed. if designate is enabled then the fqdn will be taken form the port info. in the metadata we will store the instance.hostname which will never be an fqdn in all local hostname keys. we can store teh fqdn in the public_hostname key in the ec2 metadata and in a new fqdn filed. this will make the values consitent and useful. with the new microversion we will nolonger transform the hostname except for multi-create where it will be used as a template i.e. - TBD if the new micorversion will continue to transform unicode hostname to server- or allow them out of scope for now. 3.) change workaround config option default to false enforcing the new behavior for old micorverions but do not remove it. this will enable all vm even with old clinets to have to correct behavior. of requiring the hostname to be an actul hostname we will not remove this workaround option going forward allowing cloud that want the old behavior to contiue to have it but endusers can realy on the consitent behavior by opting in to the new microverion if they have a perference. this is a log way to say that i think we need a spec for the new api behavior that adds support for FQDN offically whatever we decide we need to document the actually expected behavior in both the api refernce and general server careate doumentation. if we backport any part of this i think the new behavior should be disabled by default e.g. transfroming the numeric top level domain so that the api behavior continues to be unaffected unless operators opt in to enabling it. toughts? From fungi at yuggoth.org Mon Nov 30 20:12:38 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 30 Nov 2020 20:12:38 +0000 Subject: [ops][nova][designate] Does anyone rely on fully-qualified instance names? In-Reply-To: References: <20201130135830.q3fps4dwkxdiwngu@yuggoth.org> <20201130165039.gebc7aaxm4tw3czu@yuggoth.org> <20201130181655.tyzvbvizfbokw72q@yuggoth.org> Message-ID: <20201130201237.ql2fn6fugbwlfj6m@yuggoth.org> On 2020-11-30 19:50:22 +0000 (+0000), Sean Mooney wrote: [...] > we can generate the metadat form teh new fqdn filed. if designate > is enabled then the fqdn will be taken form the port info. in the > metadata we will store the instance.hostname which will never be > an fqdn in all local hostname keys. we can store teh fqdn in the > public_hostname key in the ec2 metadata and in a new fqdn filed. > this will make the values consitent and useful. with the new > microversion we will nolonger transform the hostname except for > multi-create where it will be used as a template i.e. name>- TBD if the new micorversion will continue to > transform unicode hostname to server- or allow them out of > scope for now. [...] If I'm understanding, this proposes to separate the instance name from the hostname, allowing them to be configured independently in API calls. If so, I agree this sounds like the sanest eventual behavior, even if getting there will require microversion bumps and non-backportable improvements. That would allow me to continue setting whatever instance names make sense for me, and I can still ignore the metadata's hostname content, but could also even start using it if it becomes a reliable way to set one across providers (in the far distant future when they've all upgraded). -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From melwittt at gmail.com Mon Nov 30 20:27:50 2020 From: melwittt at gmail.com (melanie witt) Date: Mon, 30 Nov 2020 12:27:50 -0800 Subject: [ops][nova][designate] Does anyone rely on fully-qualified instance names? In-Reply-To: References: <20201130135830.q3fps4dwkxdiwngu@yuggoth.org> <20201130165039.gebc7aaxm4tw3czu@yuggoth.org> <20201130181655.tyzvbvizfbokw72q@yuggoth.org> Message-ID: On 11/30/20 11:50, Sean Mooney wrote: > On Mon, 2020-11-30 at 18:16 +0000, Jeremy Stanley wrote: >> On 2020-11-30 10:13:00 -0800 (-0800), Michael Johnson wrote: >> [...] >>> So, I think I am in alignment with Sean. The hostname component should >>> return a 400 if there is an illegal character in the string, such as a >>> period. We also should use Punycode to store/handle unicode hostnames >>> correctly. >> [...] >> >> So to be clear, you're suggesting that if someone asks for an >> instance name which can't be converted to a (legal) hostname, then >> the nova boot call be rejected outright, even though there are >> likely plenty of people who 1. (manually) align their instance names >> with FQDNs, and 2. don't use the hostname metadata anyway? > unfortunetly we cant do that even if its the right thing to do technically. > > i think the path forward has to be something more like this. > > 1.) add a new workaround config option e.g. disable_strict_server_name_check. > for upgrade reason it would default to true in wallaby > when strict server name checking is disabled we will transform any malformed > numeric tld by replacing the '.' with '-' or by replacing the hostname with server- as we do > with unicode hostnames. Note that the model we've been using for workarounds is that they default to "False" and that users "opt in" to working around existing behavior by setting them to "True". So I think this should be something more like [workarounds]enable_strict_server_name_check = False by default and users can opt-in by setting True. > 2.) add a new api micro versions and do one of: > a.) reject servers with invlaid server names that contain '.' with a 400 > b.) transform server names according to the RFEs (replace all '.' and other disallowed charaters with -) > c.) add support for FQDNs to the api. > this coudl be something like adding a new field to store the fqdn as a top level filed on the server. > make hostname contain jsut the host name with the full FQDN in the new fqdn field. [...] This would be my preference for the long term: add a new request parameter in the API for 'hostname' using a new microversion and decouple from the display name and let the display name be a nickname for the server. This is what I hacked into the API downstream while I was at Yahoo 7-ish years ago when I was too newb to know how to propose it upstream and also hadn't yet experienced the full pain of carrying downstream patches long term. I think what I did was mostly just route the new 'hostname' request param into the existing code for the display name and then left display name alone to be only a label on the instance that is not used anywhere else. I think having the display name and hostname as separate request parameters in the API is the way we should have been doing this upstream long ago. Cheers, -melanie From johnsomor at gmail.com Mon Nov 30 21:03:49 2020 From: johnsomor at gmail.com (Michael Johnson) Date: Mon, 30 Nov 2020 13:03:49 -0800 Subject: [ops][nova][designate] Does anyone rely on fully-qualified instance names? In-Reply-To: References: <20201130135830.q3fps4dwkxdiwngu@yuggoth.org> <20201130165039.gebc7aaxm4tw3czu@yuggoth.org> <20201130181655.tyzvbvizfbokw72q@yuggoth.org> Message-ID: Yeah, I think it is important that we decouple hostname from domain as well. This will be consistent with the existing neutron API and allow proper validation of the hostname for use by the guest OS. Michael On Mon, Nov 30, 2020 at 12:31 PM melanie witt wrote: > > On 11/30/20 11:50, Sean Mooney wrote: > > On Mon, 2020-11-30 at 18:16 +0000, Jeremy Stanley wrote: > >> On 2020-11-30 10:13:00 -0800 (-0800), Michael Johnson wrote: > >> [...] > >>> So, I think I am in alignment with Sean. The hostname component should > >>> return a 400 if there is an illegal character in the string, such as a > >>> period. We also should use Punycode to store/handle unicode hostnames > >>> correctly. > >> [...] > >> > >> So to be clear, you're suggesting that if someone asks for an > >> instance name which can't be converted to a (legal) hostname, then > >> the nova boot call be rejected outright, even though there are > >> likely plenty of people who 1. (manually) align their instance names > >> with FQDNs, and 2. don't use the hostname metadata anyway? > > unfortunetly we cant do that even if its the right thing to do technically. > > > > i think the path forward has to be something more like this. > > > > 1.) add a new workaround config option e.g. disable_strict_server_name_check. > > for upgrade reason it would default to true in wallaby > > when strict server name checking is disabled we will transform any malformed > > numeric tld by replacing the '.' with '-' or by replacing the hostname with server- as we do > > with unicode hostnames. > > Note that the model we've been using for workarounds is that they > default to "False" and that users "opt in" to working around existing > behavior by setting them to "True". So I think this should be something > more like [workarounds]enable_strict_server_name_check = False by > default and users can opt-in by setting True. > > > 2.) add a new api micro versions and do one of: > > a.) reject servers with invlaid server names that contain '.' with a 400 > > b.) transform server names according to the RFEs (replace all '.' and other disallowed charaters with -) > > c.) add support for FQDNs to the api. > > this coudl be something like adding a new field to store the fqdn as a top level filed on the server. > > make hostname contain jsut the host name with the full FQDN in the new fqdn field. > [...] > > This would be my preference for the long term: add a new request > parameter in the API for 'hostname' using a new microversion and > decouple from the display name and let the display name be a nickname > for the server. > > This is what I hacked into the API downstream while I was at Yahoo 7-ish > years ago when I was too newb to know how to propose it upstream and > also hadn't yet experienced the full pain of carrying downstream patches > long term. I think what I did was mostly just route the new 'hostname' > request param into the existing code for the display name and then left > display name alone to be only a label on the instance that is not used > anywhere else. > > I think having the display name and hostname as separate request > parameters in the API is the way we should have been doing this upstream > long ago. > > Cheers, > -melanie > > From jeremy.snidaro at gmail.com Sat Nov 28 17:17:51 2020 From: jeremy.snidaro at gmail.com (Jeremy SNIDARO) Date: Sat, 28 Nov 2020 18:17:51 +0100 Subject: [training-labs] OpenStack training-labs expired link Message-ID: Hello, The scripts to setup the labs (labs-master\labs\osbash\wbatch\create_base.bat) is trying to download an version of ubuntu that is no longer available on the URL : http://cdimage.ubuntu.com/releases/18.04/release/ubuntu-18.04.4-server-amd64.iso The new URL should be : http://cdimage.ubuntu.com/releases/18.04/release/ubuntu-18.04.*5* -server-amd64.iso On github it is on the file labs/stacktrain/distros/ubuntu_18_04_server_amd64.py Regards, ----------------------------------------------------------------- Jérémy SNIDARO GNU/Linux System Administrator - DevOps jeremysnidaro.com - France 86000 Poitiers [image: LinkedIn] -------------- next part -------------- An HTML attachment was scrubbed... URL: From goel.nitish10 at gmail.com Mon Nov 30 06:51:16 2020 From: goel.nitish10 at gmail.com (Nitish Goel) Date: Mon, 30 Nov 2020 12:21:16 +0530 Subject: XDG_SESSION_TYPE error on devstack installation In-Reply-To: References: Message-ID: Openstack devstack installation went fine after exporting " XDG_SESSION_TYPE" but openstack cli didn't work Thanks, Nitish Goel On Thu, Nov 26, 2020 at 5:41 PM Nitish Goel wrote: > Thanks Balázs, > > This workaround export XDG_SESSION_TYPE='' worked for me. > > Thanks, > Nitish Goel > > On Wed, Nov 25, 2020 at 10:07 PM Balázs Gibizer > wrote: > >> >> >> On Wed, Nov 25, 2020 at 09:42, Nitish Goel >> wrote: >> > Hi Team, >> > >> > I'm trying to install a devstack on a ubuntu 18.04 VM having python >> > 3.6.9 but getting below error. Any suggestions? >> > python - 3.6.9 >> > stack user with sudo access. >> > pip version - pip 20.2.4 from >> > /usr/local/lib/python3.6/dist-packages/pip (python 3.6) >> > >> https://stackoverflow.com/questions/64989221/xdg-session-type-error-on-devstack-installation >> > NFO keystone.cmd.bootstrap [None >> > req-f46e9c41-1b14-4e5b-82b2-ada81e8b0dcd None None] Created region >> > RegionOne >> > INFO keystone.cmd.bootstrap [None >> > req-f46e9c41-1b14-4e5b-82b2-ada81e8b0dcd None None] Created public >> > endpoint http://10.61.62.241/identity >> > INFO keystone.cmd.bootstrap [None >> > req-f46e9c41-1b14-4e5b-82b2-ada81e8b0dcd None None] Created admin >> > endpoint http://10.61.62.241/identity >> > >> > >> > +./stack.sh:main:1084 create_keystone_accounts >> > +lib/keystone:create_keystone_accounts:314 local admin_project >> > ++lib/keystone:create_keystone_accounts:315 oscwrap project show >> > admin -f value -c id >> > Traceback (most recent call last): >> > File "/usr/local/bin/openstack", line 5, in >> > from openstackclient.shell import main >> > File >> > "/usr/local/lib/python3.6/dist-packages/openstackclient/shell.py", >> > line 24, in >> > from osc_lib import shell >> > File "/usr/local/lib/python3.6/dist-packages/osc_lib/shell.py", >> > line 24, in >> > from cliff import app >> > File "/usr/local/lib/python3.6/dist-packages/cliff/app.py", line >> > 24, in >> > import cmd2 >> > File "/usr/local/lib/python3.6/dist-packages/cmd2/__init__.py", >> > line 30, in >> > from .cmd2 import Cmd >> > File "/usr/local/lib/python3.6/dist-packages/cmd2/cmd2.py", line >> > 48, in >> > from .clipboard import can_clip, get_paste_buffer, >> > write_to_paste_buffer >> > File "/usr/local/lib/python3.6/dist-packages/cmd2/clipboard.py", >> > line 12, in >> > _ = pyperclip.paste() >> > File >> > "/usr/local/lib/python3.6/dist-packages/pyperclip/__init__.py", line >> > 680, in lazy_load_stub_paste >> > copy, paste = determine_clipboard() >> > File >> > "/usr/local/lib/python3.6/dist-packages/pyperclip/__init__.py", line >> > 568, in determine_clipboard >> > os.environ["XDG_SESSION_TYPE"] == "wayland" and >> > File "/usr/lib/python3.6/os.py", line 669, in __getitem__ >> > raise KeyError(key) from None >> > KeyError: 'XDG_SESSION_TYPE' >> > >> > ++functions-common:oscwrap:2346 return 1 >> > +lib/keystone:create_keystone_accounts:315 admin_project= >> > +lib/keystone:create_keystone_accounts:1 exit_trap >> > +./stack.sh:exit_trap:491 local r=1 >> > ++./stack.sh:exit_trap:492 jobs -p >> > +./stack.sh:exit_trap:492 jobs= >> > +./stack.sh:exit_trap:495 [[ -n '' ]] >> > +./stack.sh:exit_trap:501 '[' -f /tmp/tmp.LRWsRkTTkV >> > ']' >> > +./stack.sh:exit_trap:502 rm /tmp/tmp.LRWsRkTTkV >> > +./stack.sh:exit_trap:506 kill_spinner >> > +./stack.sh:kill_spinner:401 '[' '!' -z '' ']' >> > +./stack.sh:exit_trap:508 [[ 1 -ne 0 ]] >> > +./stack.sh:exit_trap:509 echo 'Error on exit' >> > Error on exit >> > +./stack.sh:exit_trap:511 type -p generate-subunit >> > +./stack.sh:exit_trap:512 generate-subunit >> > 1606228299 592 fail >> > +./stack.sh:exit_trap:514 [[ -z /opt/stack/logs ]] >> > +./stack.sh:exit_trap:517 /usr/bin/python3.6 >> > /opt/stack/devstack/tools/worlddump.py -d /opt/stack/logs >> > +./stack.sh:exit_trap:526 exit 1 >> >> >> I've seen the same error in my Ubuntu 18.04 devstack on master. I >> stopped digging when I saw that the code that blows are 15 months >> old[1]. As a workaround I did >> >> $ export XDG_SESSION_TYPE='' >> $ ./unstack.sh && ./stack.sh >> >> And it worked. >> >> [1] >> >> https://github.com/asweigart/pyperclip/blame/master/src/pyperclip/__init__.py#L568 >> >> Cheers, >> gibi >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pawel at dpnet.pl Mon Nov 30 12:06:59 2020 From: pawel at dpnet.pl (pawel at dpnet.pl) Date: Mon, 30 Nov 2020 13:06:59 +0100 Subject: [designate] DKIM TXT record problem Message-ID: <2f6b2699c225afa34a4a98a5ebf039c6@dpnet.pl> I have the same problem, would you like to share a command line example, how did you manage to add such a long txt record in the designate (more than 255 characters in one record)? -- Pawel D