July 2020 - openstack-discuss - lists.openstack.org

[openstack][octavia] transparent
by Ignazio Cassano 17 Jul '20

17 Jul '20

Hello all, I have some end users who want to receive on their load balanced web servers the client ip address for acl. They also want the https connection is terminated on web servers and not on load balancer. Can I solve with octavia ? I read haproxy can act as transparent only when it is the default router of backends. In our use case the default router is not the load balancer. Any help, please? Ignazio

3 7

[TripleO]Documentation to list all options in yaml file and possible values
by Ruslanas Gžibovskis 16 Jul '20

16 Jul '20

Hi all, 1) Is there a page or a draft, where all options of TripleO are available? 2) Is there a page or a draft, where dependencies of each option are listed? 3) Is there a page or a draft, where all possible values for each option would be listed? -- Ruslanas Gžibovskis +370 6030 7030

2 1

10 years of OpenStack virtual celebration - recordings
by Sunny Cai 16 Jul '20

16 Jul '20

Hello everyone, We just had the 10 years of OpenStack virtual celebration with the community members around the world. It was a huge success and thanks to everyone who have joined the community meeting. If you have missed the meeting or what a replay, here you can find the meeting recording and the slide deck: 10 years of OpenStack celebration recording: https://www.youtube.com/watch?v=QYhK0219LIk&feature=youtu.be <https://www.youtube.com/watch?v=QYhK0219LIk&feature=youtu.be> Slide deck: https://docs.google.com/presentation/d/1bPJYOGVDypcXiNaddoPY9o1Wh-thZeuL-y8… <https://docs.google.com/presentation/d/1bPJYOGVDypcXiNaddoPY9o1Wh-thZeuL-y8…> Check out the 10 years of OpenStack blog here: https://www.openstack.org/blog/thank-you-to-the-last-decade-hello-to-the-ne… <https://www.openstack.org/blog/thank-you-to-the-last-decade-hello-to-the-ne…> Here I have attached a few screenshots from the virtual celebration. Happy 10 years of OpenStack and take care! Thanks, Sunny Cai OpenStack Foundation sunny(a)openstack.org <mailto:sunny@openstack.org>

1 0

Kolla Klub
by Radosław Piliszek 16 Jul '20

16 Jul '20

Hi Folks, The Kolla Klub is on. Sorry for the late reminder. The meeting url has changed a bit because it cannot be hosted by Mark today. Meeting link: https://meet.google.com/bpx-ymco-cfy Kolla Klub in docs: https://docs.google.com/document/d/1EwQs2GXF-EvJZamEx9vQAOSDB5tCjsDCJyHQN5_… -yoctozepto

1 0

10 Years of OpenStack Celebration - 8:00am PST (1500 UTC)
by Sunny Cai 16 Jul '20

16 Jul '20

Hello everyone, The 10 years of OpenStack virtual celebration is starting in one hour! Join us and many of the original Stackers who helped form the project back in 2010 to celebrate the past 10 years. The meeting starts today at 8:00am PST (1500 UTC). Please see the etherpad for more meeting information: https://etherpad.opendev.org/p/tTP9ilsAaJ2E8vMnm6uV <https://etherpad.opendev.org/p/tTP9ilsAaJ2E8vMnm6uV> Thanks, Sunny Cai OpenStack Foundation sunny(a)openstack.org

1 0

[manila] No IRC meeting on 16th July 2020
by Goutham Pacha Ravi 15 Jul '20

15 Jul '20

Hello Zorillas and Interested Stackers, I clearly missed the overlap our IRC meeting had with the OpenStack Community Meeting (invite/information in the latter part of this email). This is an important one for all of us to attend if we can, and toast this amazing community, of which we are a small part. There were no new agenda items added for this week's meeting, so we'll push any discussion items to the next meeting. In the meantime, please note: - a kernel bug in Ubuntu 18.04 [1][2] currently causes test dsvm nodes on RAX to reboot when running the LVM job. We're currently skipping scenario tests in the LVM job to workaround the issue. This bug has been fixed in a new kernel version, we'll re-enable scenario tests when we don't see the issue occurring on RAX. - Manila's new driver deadline is the week of Jul 27 - Jul 31. Please interact with us on #openstack-manila should you have any concern with this deadline. - please review the specifications, they will need to be merged before the next week's meeting Hope to see you at the community meeting! Goutham Pacha Ravi [1] https://launchpad.net/bugs/1886988 [2] https://launchpad.net/bugs/1886668 ---------- Forwarded message --------- From: Sunny Cai <sunny(a)openstack.org> Date: Wed, Jul 8, 2020 at 2:38 PM Subject: July OSF Community Meeting - 10 Years of OpenStack To: <openstack-discuss(a)lists.openstack.org> Hello everyone, You might have heard that OpenStack is turning 10 this year! On *Thursday*, *July 16 at 8am PT (1500 UTC)*, we will be holding the 10 years of OpenStack virtual celebration in the July OSF community meeting. I have attached the calendar invite for the July OSF community meeting below. Grab your favorite OpenStack swag and bring your favorite drinks of choice to the meeting on July 16. Let’s do a virtual toast to the 10 incredible years! Please see the etherpad for more meeting information: https://etherpad.opendev.org/p/tTP9ilsAaJ2E8vMnm6uV If you have any questions, please let me know. P.S. To add more fun, feel free to try out the virtual background feature in Zoom. The 10 years of OpenStack virtual background is attached below. Thanks, Sunny Cai OpenStack Foundation sunny(a)openstack.org

1 0

[Tripleo] Planned outage of review.rdoproject.org: 2020-07-15 from 18:00 to 20:00 UTC
by Nicolas Hicher 15 Jul '20

15 Jul '20

Hello folks, Our cloud provider plans to do maintainance operation on 2020-07-15 from 18:00 to 20:00 UTC. Service interruption is expected, including: - Zuul CI not running jobs for gerrit, github or opendev. - RDO Trunk not building new packages. - DLRN API. - review.rdoproject.org and softwarefactory-project.io gerrit service. Regards, Nicolas, on behalf of the Software Factory Operation Team

1 0

[horizon] No meeting today
by Ivan Kolodyazhny 15 Jul '20

15 Jul '20

Hi team, I can't attend the meeting today, so let's skip it. If you've got any topics to discuss today we can do it in #openstack-horizon IRC channel. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/

1 0

[ideas] 3 new project drafts
by Jonathan de Jong 15 Jul '20

15 Jul '20

Heya OpenStack community! The openstack-ideas website inspired me to create 3 more ideas, each based on some personal experiences and musings which OpenStack could address. Project "Dew": https://review.opendev.org/741008 (low-spec cloud computing) Project "Nebula": https://review.opendev.org/741057 (interface translation for plural or propriatary clouds) Project "Aurora": https://review.opendev.org/741165 (communal/collaborative cloud computing) I need to admit that these drafts are in my opnion extremely rough, very biased, and probably need to be rewritten several times. So that's why I invite people to discuss specifics and implementations of these ideas. If aspects of these ideas are similes of past proposals or projects, which have then been debunked/abandoned, i'm curious as to what discussion has happened for it to be rejected that way. If my language in these drafts are unreadable, confusing, simply too vague, or any other combination of sub-standard writing, please let me know. I plan to expand/improve/detail these project drafts from feedback and comments, please share if any of that comes to mind. Thanks in advance! - Jonathan de Jong

1 0

Re: device compatibility interface for live migration with assigned devices
by Sean Mooney 14 Jul '20

14 Jul '20

resending with full cc list since i had this typed up i would blame my email provier but my email client does not seam to like long cc lists. we probably want to continue on alex's thread to not split the disscusion. but i have responed inline with some example of how openstack schdules and what i ment by different mdev_types On Tue, 2020-07-14 at 20:29 +0100, Sean Mooney wrote: > On Tue, 2020-07-14 at 11:01 -0600, Alex Williamson wrote: > > On Tue, 14 Jul 2020 13:33:24 +0100 > > Sean Mooney <smooney(a)redhat.com> wrote: > > > > > On Tue, 2020-07-14 at 11:21 +0100, Daniel P. Berrangé wrote: > > > > On Tue, Jul 14, 2020 at 07:29:57AM +0800, Yan Zhao wrote: > > > > > hi folks, > > > > > we are defining a device migration compatibility interface that helps upper > > > > > layer stack like openstack/ovirt/libvirt to check if two devices are > > > > > live migration compatible. > > > > > The "devices" here could be MDEVs, physical devices, or hybrid of the two. > > > > > e.g. we could use it to check whether > > > > > - a src MDEV can migrate to a target MDEV, > > > > > > mdev live migration is completely possible to do but i agree with Dan barrange's comments > > > from the point of view of openstack integration i dont see calling out to a vender sepecific > > > tool to be an accpetable > > > > As I replied to Dan, I'm hoping Yan was referring more to vendor > > specific knowledge rather than actual tools. > > > > > solutions for device compatiablity checking. the sys filesystem > > > that describs the mdevs that can be created shoudl also > > > contain the relevent infomation such > > > taht nova could integrate it via libvirt xml representation or directly retrive the > > > info from > > > sysfs. > > > > > - a src VF in SRIOV can migrate to a target VF in SRIOV, > > > > > > so vf to vf migration is not possible in the general case as there is no standarised > > > way to transfer teh device state as part of the siorv specs produced by the pci-sig > > > as such there is not vender neutral way to support sriov live migration. > > > > We're not talking about a general case, we're talking about physical > > devices which have vfio wrappers or hooks with device specific > > knowledge in order to support the vfio migration interface. The point > > is that a discussion around vfio device migration cannot be limited to > > mdev devices. > > ok upstream in openstack at least we do not plan to support generic livemigration > for passthough devivces. we cheat with network interfaces since in generaly operating > systems handel hotplug of a nic somewhat safely so wehre no abstraction layer like > an mdev is present or a macvtap device we hot unplug the nic before the migration > and attach a new one after. for gpus or crypto cards this likely would not be viable > since you can bond generic hardware devices to hide the removal and readdtion of a generic > pci device. we were hoping that there would be a convergenca around MDEVs as a way to provide > that abstraction going forward for generic device or some other new mechanisum in the future. > > > > > > > - a src MDEV can migration to a target VF in SRIOV. > > > > > > that also makes this unviable > > > > > (e.g. SIOV/SRIOV backward compatibility case) > > > > > > > > > > The upper layer stack could use this interface as the last step to check > > > > > if one device is able to migrate to another device before triggering a real > > > > > live migration procedure. > > > > > > well actully that is already too late really. ideally we would want to do this compaiablity > > > check much sooneer to avoid the migration failing. in an openstack envionment at least > > > by the time we invoke libvirt (assuming your using the libvirt driver) to do the migration we have alreaedy > > > finished schduling the instance to the new host. if if we do the compatiablity check at this point > > > and it fails then the live migration is aborted and will not be retired. These types of late check lead to a > > > poor user experince as unless you check the migration detial it basically looks like the migration was ignored > > > as it start to migrate and then continuge running on the orgininal host. > > > > > > when using generic pci passhotuhg with openstack, the pci alias is intended to reference a single vendor > > > id/product > > > id so you will have 1+ alias for each type of device. that allows openstack to schedule based on the availability > > > of > > > a > > > compatibale device because we track inventories of pci devices and can query that when selecting a host. > > > > > > if we were to support mdev live migration in the future we would want to take the same declarative approch. > > > 1 interospec the capability of the deivce we manage > > > 2 create inventories of the allocatable devices and there capabilities > > > 3 schdule the instance to a host based on the device-type/capabilities and claim it atomicly to prevent raceces > > > 4 have the lower level hyperviors do addtional validation if need prelive migration. > > > > > > this proposal seams to be targeting extending step 4 where as ideally we should focuse on providing the info that > > > would > > > be relevant in set 1 preferably in a vendor neutral way vai a kernel interface like /sys. > > > > I think this is reading a whole lot into the phrase "last step". We > > want to make the information available for a management engine to > > consume as needed to make informed decisions regarding likely > > compatible target devices. > > well openstack as a management engin has 3 stages for schdule and asignment,. > in respocne to a live migration request the api does minimal valaidation then hand the task off to the conductor > service > ot orchestrate. the conductor invokes an rpc to the schduler service which makes a rest call to the plamcent service. > the placment cervice generate a set of allocation candiate for host based on qunataive and qulaitivly > queries agains an abstract resouce provider tree model of the hosts. > currently device pasthough is not modeled in placment so plamcnet is basicaly returning a set of host that have enough > cpu ram and disk for the instance. in the spacial of vGPU they technically are modelled in placement but not in a way > that would gurarentee compatiablity for migration. a generic pci device request is haneled in the second phase of > schduling called filtering and weighing. in this pahse the nova schuleer apply a series of filter to the list of host > returned by plamcnet to assert things like anit afintiy, tenant isolation or in the case of this converation nuam > affintiy and pci device avaiablity. when we have filtered the posible set of host down to X number we weigh the > listing > to select an optimal host and set of alternitive hosts. we then enter the code that this mail suggest modfiying which > does an rpc call to the destiation host form teh conductor to have it assert compatiablity which internaly calls back > to > the sourc host. > > so my point is we have done a lot of work by the time we call check_can_live_migrate_destination and failing > at this point is considerd quite a late failure but its still better then failing when qemu actully tries to migrate. > in general we would prefer to move compatiablity check as early in that workflow as possible but to be fair we dont > actully check cpu model compatiablity until check_can_live_migrate_destination. > https://github.com/openstack/nova/blob/8988316b8c132c9662dea6cf0345975e87ce… > > if we needed too we could read the version string on the source and write the version string on the dest at this > point. > doing so however would be considerd, inelegant, we have found this does not scale as the first copmpatabilty check. > for cpu for example there are way to filter hosts by groups sets fo host with the same cpu or filtering on cpu feature > flags that happen in the placment or filter stage both of which are very early and cheap to do at runtime. > > the "read for version, write for compatibility" workflow could be used as a final safe check if required but > probing for compatibility via writes is basicaly considered an anti patteren in openstack. we try to always > assert compatibility by reading avaiable info and asserting requirement over it not testing to see if it works. > > this has come up in the past in the context of virtio feature flag where the idea of spawning an instrance or trying > to add a virtio port to ovs dpdk that reqested a specific feature flag was rejected as unacceptable from a performance > and security point of view. > > > > > > > > we are not sure if this interface is of value or help to you. please don't > > > > > hesitate to drop your valuable comments. > > > > > > > > > > > > > > > (1) interface definition > > > > > The interface is defined in below way: > > > > > > > > > > __ userspace > > > > > /\ \ > > > > > / \write > > > > > / read \ > > > > > ________/__________ ___\|/_____________ > > > > > | migration_version | | migration_version |-->check migration > > > > > --------------------- --------------------- compatibility > > > > > device A device B > > > > > > > > > > > > > > > a device attribute named migration_version is defined under each device's > > > > > sysfs node. e.g. (/sys/bus/pci/devices/0000\:00\:02.0/$mdev_UUID/migration_version). > > > > > > this might be useful as we could tag the inventory with the migration version and only might to > > > devices with the same version > > > > Is cross version compatibility something that you'd consider using? > > yes but it would depend on what cross version actully ment. > > the version of an mdev is not something we would want to be exposed to endusers. > it would be a security risk to do so as the version sting would potentaily allow the untrused user > to discover if a device has an unpatch vulnerablity. as a result in the context of live migration > we can only support cross verion compatiabilyt if the device in the guest does not alter as > part of the migration and the behavior does not change. > > going form version 1.0 with feature X to verions 1.1 with feature X and Y but only X enabled would > be fine. going gorm 1.0 to 2.0 where thre is only feature Y would not be ok. > being abstract makes it a little harder to readabout but i guess i would sumerisei if its > transparent to the guest for the lifetime of the qemu process then its ok for the backing version to change. > if a vm is rebooted its also ok fo the vm to pick up feature Y form the 1.1 device although at that point > it could not be migrated back to the 1.0 host as it now has feature X and Y and 1.0 only has X so that woudl be > an obserable change if it was drop as a reult of the live migration. > > > > > > > userspace tools read the migration_version as a string from the source device, > > > > > and write it to the migration_version sysfs attribute in the target device. > > > > > > this would not be useful as the schduler cannot directlly connect to the compute host > > > and even if it could it would be extreamly slow to do this for 1000s of hosts and potentally > > > multiple devices per host. > > > > Seems similar to Dan's requirement, looks like the 'read for version, > > write for compatibility' test idea isn't really viable. > > its ineffiecnt and we have reject adding such test in the case of virtio-feature flag compatiabilty > in the past, so its more an option of last resourt if we have no other way to support compatiablity > checking. > > > > > > > > > > > > The userspace should treat ANY of below conditions as two devices not compatible: > > > > > - any one of the two devices does not have a migration_version attribute > > > > > - error when reading from migration_version attribute of one device > > > > > - error when writing migration_version string of one device to > > > > > migration_version attribute of the other device > > > > > > > > > > The string read from migration_version attribute is defined by device vendor > > > > > driver and is completely opaque to the userspace. > > > > > > opaque vendor specific stings that higher level orchestros have to pass form host > > > to host and cant reason about are evil, when allowed they prolifroate and > > > makes any idea of a vendor nutral abstraction and interoperablity between systems > > > impossible to reason about. that said there is a way to make it opaue but still useful > > > to userspace. see below > > > > > for a Intel vGPU, string format can be defined like > > > > > "parent device PCI ID" + "version of gvt driver" + "mdev type" + "aggregator count". > > > > > > > > > > for an NVMe VF connecting to a remote storage. it could be > > > > > "PCI ID" + "driver version" + "configured remote storage URL" > > > > > > > > > > for a QAT VF, it may be > > > > > "PCI ID" + "driver version" + "supported encryption set". > > > > > > > > > > (to avoid namespace confliction from each vendor, we may prefix a driver name to > > > > > each migration_version string. e.g. i915-v1-8086-591d-i915-GVTg_V5_8-1) > > > > > > honestly i would much prefer if the version string was just a semver string. > > > e.g. {major}.{minor}.{bugfix} > > > > > > if you do a driver/frimware update and break compatiablity with an older version bump the > > > major version. > > > > > > if you add optional a feature that does not break backwards compatiablity if you migrate > > > an older instance to the new host then just bump the minor/feature number. > > > > > > if you have a fix for a bug that does not change the feature set or compatiblity backwards or > > > forwards then bump the bugfix number > > > > > > then the check is as simple as > > > 1.) is the mdev type the same > > > 2.) is the major verion the same > > > 3.) am i going form the same version to same version or same version to newer version > > > > > > if all 3 are true we can migrate. > > > e.g. > > > 2.0.1 -> 2.1.1 (ok same major version and migrating from older feature release to newer feature release) > > > 2.1.1 -> 2.0.1 (not ok same major version and migrating from new feature release to old feature release may be > > > incompatable) > > > 2.0.0 -> 3.0.0 (not ok chaning major version) > > > 2.0.1 -> 2.0.0 (ok same major and minor version, all bugfixs in the same minor release should be compatibly) > > > > What's the value of the bugfix field in this scheme? > > its not require but really its for a non visable chagne form a feature standpoint. > a rather contrived example but if it was quadratic to inital a set of queues or device bufferes > in 1.0.0 and you made it liniar in 1.0.1 that is a performace improvment in the device intialisation time > which is great but it would not affect the feature set or compatiablity in any way. you could call it > a feature but its really just an internal change but you might want to still bump the version number. > > > > The simplicity is good, but is it too simple. It's not immediately > > clear to me whether all features can be hidden behind a minor version. > > For instance, if we have an mdev device that supports this notion of > > aggregation, which is proposed as a solution to the problem that > > physical hardware might support lots and lots of assignable interfaces > > which can be combined into arbitrary sets for mdev devices, making it > > impractical to expose an mdev type for every possible enumeration of > > assignable interfaces within a device. > > so this is a modeling problem and likely a limitation of the current way an mdev_type is exposed. > stealing some linux doc eamples > > > |- [parent physical device] > |--- Vendor-specific-attributes [optional] > |--- [mdev_supported_types] > | |--- [<type-id>] > | | |--- create > | | |--- name > | | |--- available_instances > | | |--- device_api > | | |--- description > > you could adress this in 1 of at least 3 ways. > 1.) mdev type for each enmartion which is fine for 1-2 variabley othersize its a combinitroial explotions. > 2.) report each of the consomable sub componetns as an mdev type and create mupltipel mdevs and assign them to the vm. > 3.) provider an api to dynamically compose mdevs types which staticaly partion the reqouese and can then be consomed > perferably embeding the resouce infomation in the description filed in a huma/machince readable form. > > 2 and 3 woudl work well with openstack however they both have there challanges > 1 doesnt really work for anyone out side of a demo. > > We therefore expose a base type > > where the aggregation is built later. This essentially puts us in a > > scenario where even within an mdev type running on the same driver, > > there are devices that are not directly compatible with each other. > > > > > we dont need vendor to rencode the driver name or vendor id and product id in the string. that info is alreay > > > available both to the device driver and to userspace via /sys already we just need to know if version of > > > the same mdev are compatiable so a simple semver version string which is well know in the software world > > > at least is a clean abstration we can reuse. > > > > This presumes there's no cross device migration. > > no but it does assume no cross mdev_type migration. > it assuems that nvida_mdev_type_x on host 1 is the same as nvida_mdev_type_x on host 2. > if the parent device differese but support the same mdev type we are asserting that they > should be compatiable or a differnt mdev_type name should be used on each device. > > so we are presuming the mdev type cant change as part of a live migration and if the type > was to change it would no longer be a live migration operation it would be something else. > that is based on the premis that changing the mdev type would change the capabilities of the mdev > > > An mdev type can only > > be migrated to the same mdev type, all of the devices within that type > > have some based compatibility, a phsyical device can only be migrated to > > the same physical device. In the latter case what defines the type? > > the type-id in /sysfs > > /sys/devices/virtual/mtty/mtty/ > |-- mdev_supported_types > | |-- mtty-1 <---- this is an mdev type > | | |-- available_instances > | | |-- create > | | |-- device_api > | | |-- devices > | | `-- name > | `-- mtty-2 <---- as is this > | |-- available_instances > | |-- create > | |-- device_api > | |-- devices > | `-- name > > |- [parent phy device] > |--- [$MDEV_UUID] > |--- remove > |--- mdev_type {link to its type} <-- here > |--- vendor-specific-attributes [optional] > > > If > > it's a PCI device, is it only vendor:device IDs? > > no the mdev type is not defined by the vendor:device id of the parent device > although the capablityes of that device will determin what mdev types if any it supprots. > > What about revision? > > What about subsystem IDs? > > at least for nvidia gpus i dont think if you by an evga branded v100 vs an pny branded one the capability > would change but i do know that certenly the capablities of a dell branding intel nic and an intel branded > one can. e.g. i have seen oem sku nics without sriov eventhoguh the same nic form intel supports it. > sriov was deliberatly disabled in the dell firmware even though it share dhte same vendor and prodcut id but differnt > subsystem id. > > if the odm made an incomatipable change like that which affect an mdev type in some way i guess i would expect them to > change the name or the description filed content to signal that. > > > What about possibly an onboard ROM or > > internal firmware? > > i would expect that updating the firmware/rom could result in changing a version string. that is how i was imagining > it would change. > > The information may be available, but which things > > are relevant to migration? > > that i dont know an i really would not like to encode that knolage in the vendor specific way in higher level > tools like openstack or even libvirt. declarative version sting comparisons or even simile feature flag > check where an abstract huristic that can be applied across vendors would be fine. but yes i dont know > what info would be needed in this case. > > We already see desires to allow migration > > between physical and mdev, > > migration between a phsical device and an mdev would not generally be considered a live migration in openstack. > that would be a different operation as it would be user visible withing the guest vm. > > but also to expose mdev types that might be > > composable to be compatible with other types. Thanks, > > i think composable mdev types are really challanging without some kind of feature flag concept > like cpu flags or ethtool nic capablities that are both human readable and easily parsable. > > we have the capability to schedule on cpu flags or gpu cuda level using a traits abstraction > so instead of saying i want an vm on a host with an intel 2695v3 to ensure it has AVX > you say i want an vm that is capable of using AVX > https://github.com/openstack/os-traits/blob/master/os_traits/hw/cpu/x86/__i… > > we also have trait for cuda level so instead of asking for a specifc mdev type or nvida > gpu the idea was you woudl describe what feature cuda in this exmple you need > https://github.com/openstack/os-traits/blob/master/os_traits/hw/gpu/cuda.py… > > That is what we call qualitative schudleing and is why we create teh placement service. > with out going in to the weeds we try to decouple quantaitive request such as 4 cpus and 1G of ram > form the qunative i need AVX supprot > > e.g. resouces:VCPU=4,resouces:MEMORY_MB=1024 triats:required=HW_CPU_X86_AVX > > declarative quantitive and capablites reporting of resouces fits easily into that model. > dynamic quantities that change as other mdev are allocated from the parent device or as > new mdevs types are composed on the fly are very challenging. > > > > > Alex > > > >

1 0

[octavia] Replace broken amphoras
by Fabian Zimmermann 14 Jul '20

14 Jul '20

Hi, we had some network issues and now have amphoras which are marked in ERROR state. What we already tried: - failover the amphora - failover the loadbalancer both did not work, got "unable to attach port to (new) amphora". Then we removed the vrrp_port, set the vrrp_port_id to NULL and repeated the amphora failover Reverting Err: "PortID: Null" Then we created a new vrrp_port as described [1] and added the port-id to the vrrp_port_id and the a suitable vrrp_ip field to our ERRORed amphora entry. Restarted failover -> without luck. Currently we have an single STANDALONE amphora configured. Is there a way to trigger octavia to create new "clean" amphoras for MASTER/BACKUP? Thanks, Fabian [1] http://eavesdrop.openstack.org/irclogs/%23openstack-lbaas/%23openstack-lbaa…

2 3

Cloud Computing Resource
by supriya katal 14 Jul '20

14 Jul '20

Hello Team I have checked your sites. https://github.com/openstacknetsdk/openstack.net/wiki/Getting-Started-With-… For using this sdk, one needs to create an account for *RECKSPACE *open cloud. I have an account in STACKPATH https://control.stackpath.com/ Can I use a stackpath storage object for uploading and accessing the files? I have tried to use your api for uploading and accessing files of STACKPATH object storage. https://docs.openstack.org/api-ref/object-store/index.html?expanded=create-… but I got an error of Access Denied.

2 1

[security] Security SIG meeting July 16th 2020 canceled
by Gage Hugo 14 Jul '20

14 Jul '20

Hello everyone, The security sig meeting this week will be cancelled due to the 10 years of openstack celebration happening at the same time. We will meet next week at the scheduled time.

1 0

[cinder] cinderlib reviews needed
by Brian Rosmaita 14 Jul '20

14 Jul '20

cinderlib is on a cycle-trailing release model and the Ussuri release is coming up soon. Because it's still a new project, I thought I'd send a reminder in case it fell off your radar. These patches need to merge before we cut the release: https://review.opendev.org/720553 https://review.opendev.org/738226 https://review.opendev.org/738473 https://review.opendev.org/739190 https://review.opendev.org/738230 https://review.opendev.org/738866 https://review.opendev.org/738472 https://review.opendev.org/738213 They each have a single +2 at the moment, and they are all short, focused patches. cheers, brian

2 1

[TripleO][CentOS8][Ussuri] overcloud-full image creation to add kernel options and proxy and others
by Ruslanas Gžibovskis 14 Jul '20

14 Jul '20

Hi all, Borry to keep spamming you all the time. But could you help me to find a correct place to "modify" image content (packages installed and not installed) and files and services configured in an "adjusted" way so I would have for example: - tuned ssh - automatically generated root pass to the one I need - Also added proxy config to /etc/yum.conf to certain computes, and other would be used without proxy (maybe extraconfig option?) - set up kernel parameters, so I would have console output duplicated to serial connection and to iDRAC serial, so I could see login screen over idrac ssh. - and so on. I believe many of those things can be done over extraconfig, I just do not know options to modify. maybe you can point me like a blind hen into a correct bowl? :))) Thank you in advance. -- Ruslanas Gžibovskis +370 6030 7030

2 6

[ceilometer][octavia] polling meters
by Ionut Biru 14 Jul '20

14 Jul '20

Hello guys, I was trying to add in polling.yaml and pipeline from ceilometer the following: - network.services.lb.active.connections - network.services.lb.health_monitor - network.services.lb.incoming.bytes - network.services.lb.listener - network.services.lb.loadbalancer - network.services.lb.member - network.services.lb.outgoing.bytes - network.services.lb.pool - network.services.lb.total.connections But it doesn't work, I think they are for the old lbs that were supported in neutron. I found https://docs.openstack.org/ceilometer/latest/admin/telemetry-dynamic-pollst… but this is not available in stein or train. I was wondering if there is a way to meter loadbalancers from octavia. I mostly want for start to just meter if a loadbalancer was deployed and has status active. -- Ionut Biru - https://fleio.com

3 17

[neutron] Bug deputy report for week of July 6th
by Brian Haley 13 Jul '20

13 Jul '20

Hi, I was Neutron bug deputy last week. Below is a short summary about reported bugs. -Brian Critical bugs ------------- * https://bugs.launchpad.net/neutron/+bug/1886807 - neutron-ovn-tempest-full-multinode-ovs-master job is failing 100% times - Gate failure High bugs --------- * https://bugs.launchpad.net/neutron/+bug/1886956 - Functional test test_restart_wsgi_on_sighup_multiple_workers is failing sometimes - https://review.opendev.org/#/c/740283/ * https://bugs.launchpad.net/neutron/+bug/1886969 - dhcp bulk reload fails with python3 - needs owner * https://bugs.launchpad.net/neutron/+bug/1887148 - Network loop between physical networks with DVR - https://review.opendev.org/#/c/740724/ proposed Medium bugs ----------- * https://bugs.launchpad.net/neutron/+bug/1886909 - selection_fields for udp and sctp case doesn't work correctly - This is actually a bug in core OVN, and fixed in v20.06.1, should bump to test with a later version - Also related to supporting SCTP w/Octavia and adding that support to the ovn-octavia-provider driver * https://bugs.launchpad.net/neutron/+bug/1886962 - [OVN][QOS] NBDB qos table entries still exist even after corresponding neutron ports are deleted - needs owner * https://bugs.launchpad.net/neutron/+bug/1887108 - wrong l2pop flows on vlan network - asked for more information on config - needs owner * https://bugs.launchpad.net/neutron/+bug/1887163 - Failed to create network or port with dns_domain parameter - possible config issue with two dns extensions loaded at same time Low bugs -------- * https://bugs.launchpad.net/neutron/+bug/1887147 - neutron-linuxbridge-agent looping same as dhcp - actually looks like a configuration issue in the deployment as privsep helper isn't able to start properly Wishlist bugs ------------- * https://bugs.launchpad.net/neutron/+bug/1886798 - [RFE] Port NUMA affinity policy - Port object update for Nova scheduling - Needs discussion in Drivers meeting Further triage required ----------------------- * https://bugs.launchpad.net/neutron/+bug/1886426 - Neutron sending response to rabbitmq exchange with event type "floatingip.update.end" without updating the status of Floating IP - Asked for more information * https://bugs.launchpad.net/neutron/+bug/1886949 - [RFE] Granular metering data in neutron-metering-agent - Update to metering agent - Asked Slawek to take a look as there was talk about deprecating the metering agent

1 0

[tripleo] TripleO CI Summary: Unified Sprint 29
by Rafael Folco 13 Jul '20

13 Jul '20

Greetings, The TripleO CI team has just completed **Unified Sprint 29** (June 18 thru July 08). The following is a summary of completed work during this sprint cycle [1]: - Continued building internal component and integration pipelines. - Designed new promoter tests to run on Python3 to reuse common code and adapt molecule scenarios to the new test sequence standard. Design doc can be found at https://hackmd.io/kJqHSTWWRMOIfIhvDMGFLg. - Important changes to the next-generation promoter have been submitted, e.g. QCOW2 promotions https://review.rdoproject.org/r/#/c/27626/. - CentOS8 component and integration pipelines are still in progress to be completed in the next sprint cycle. - Tempest skip list and ironic plugin general improvements. - Ruck/Rover recorded notes [2]. The planned work for the next sprint [3] extends the work started in the previous sprint and focuses on switching container build jobs to the new building system. The Ruck and Rover for this sprint are Sandeep Yadav (ysandeep), Sorin Sbarnea (zbr). 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 etherpad [4]. Thanks, rfolco [1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-29 [2] https://hackmd.io/XcuH2OIVTMiuxyrqSF6ocw [3] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-30 [4] https://hackmd.io/6Bx0FXwlRNCc75l39NSKvg -- Folco

1 0

[tc] weekly update
by Mohammed Naser 13 Jul '20

13 Jul '20

Hi everyone, Here’s an update for what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. We've also included a few references to some important mailing list threads that you should check out. # Patches ## Open Reviews - [manila] assert:supports-accessible-upgrade https://review.opendev.org/740509 - Add legacy repository validation https://review.opendev.org/737559 - Cleanup the remaining osf repos and their data https://review.opendev.org/739291 - [draft] Add assert:supports-standalone https://review.opendev.org/722399 ## General Changes - Create starter-kit:kubernetes-in-virt tag https://review.opendev.org/736369 - Update goal selection docs to clarify the goal count https://review.opendev.org/739150 - Add "tc:approved-release" tag to manila https://review.opendev.org/738105 # Email Threads - New Office Hours: http://lists.openstack.org/pipermail/openstack-discuss/2020-July/015761.html - Summit CFP Open: http://lists.openstack.org/pipermail/openstack-discuss/2020-July/015730.html # Other Reminders - OpenStack's 10th anniversary community meeting should be happening July 16th: more info coming soon! - If you're an operator, make sure you fill out our user survey: https://www.openstack.org/user-survey/survey-2020/ - Milestone 2 coming at the end of the month Thanks for reading! Mohammed & Kendall -- Mohammed Naser VEXXHOST, Inc.

1 0

[magnum] failed to launch Kubernetes cluster
by Tony Pearce 13 Jul '20

13 Jul '20

Hi team, I hope you are all keeping safe and well at the moment. I am trying to use magnum to launch a kubernetes cluster. I have tried different images but currently using Fedora-Atomic 27. The cluster deployment from the cluster template is failing and I am here to ask if you could please point me in the right direction? I have become stuck and I am uncertain how to further troubleshoot this. The cluster seems to fail a few minutes after booting up the master node because after I see the logs ([1],[2]), I do not see any progress in terms of new (different) logs or load on the master. Then the 60-minute timeout is reached and fails the cluster. I deployed this openstack stack using kayobe (kolla-ansible) and this is version Train. This is deployed on CentOS 7 within docker containers. Kayobe manages this deployment through the ansible playbooks. This was previously working some months back although I think I may have used coreos image at that time, and that is also not working today. The deployment would have been back around February 2020. I then deleted that deployment and re-deployed. The only change being the hostname for controller node as updated in the inventory file for the kayobe. Since then which was a month or so back I've been unable to successfully deploy a kubernetes cluster. I've tried other fedora-atomic images as well as coreos without success. When using the coreos image and when tagging the image with the coreos tag as per the magnum docs, the instance fails to boot and goes to the rescue shell. However if I manually launch the coreos image then it does successfully boot and get configured via cloud-init. All of the deployment attempts stop at the same place when using fedora image and I have a different experience if I disable TLS: TLS enabled: master launched, no nodes. Fails when running /usr/lib/python2.7/site-packages/magnum/drivers/k8s_fedora_atomic_v1/templates/kubemaster.yaml TLS disabled: master and nodes launched but later fails. I didnt investigate this very much. When looking for help around the web, I found this which looks to be the same issue that I have at the moment (although he's deployed slightly differently, using centos8 and mentions magnum 10): https://ask.openstack.org/en/question/128391/magnum-ussuri-container-not-bo… I have the same log messages on the master node within heat. When going through the troubleshooting guide I see that etcd is running and no errors however I dont see any flannel service at all. But I also don't know if this has simply failed before getting to deploy flannel or whether flannel is the reason. I did try to deploy using a cluster template that is using calico as a test but the same result from the logs. When looking at the stack via cli to see the failed stacks this is what I see there: http://paste.openstack.org/show/795736/ I'm using master node flavour with 4cpu and 4GB memory. Node with 2cpu and 2GB memory. Storage is only via cinder as I am using iscsi storage with a cinder driver. I dont have any other storage. On the master, after the failure the heat log repeats these logs: ++ curl --silent http://127.0.0.1:8080/healthz + '[' ok = ok ']' + kubectl patch node k8s-cluster-onvaoh2zxotf-master-0 --patch '{"metadata": {"labels": {"node-role.kubernetes.io/master": ""}}}' error: no configuration has been provided, try setting KUBERNETES_MASTER environment variable Trying to label master node with node-role.kubernetes.io/master="" + echo 'Trying to label master node with node-role.kubernetes.io/master=""' + sleep 5s [1]Here's the cloud-init.log: http://paste.openstack.org/show/795737/ [2]and cloud-init-output.log: http://paste.openstack.org/show/795738/ May I ask if anyone has a recent deployment of Magnum and a working deployment of kubernetes that could share with me the relevant details like the image you have used so that I can try and replicate? To create the cluster template I have been using: openstack coe cluster template create k8s-cluster-template \ --image Fedora-Atomic-27 \ --keypair testpair \ --external-network physnet2vlan20 \ --dns-nameserver 192.168.7.233 \ --flavor 2GB-2vCPU \ --docker-volume-size 15 \ --network-driver flannel \ --coe kubernetes If I have missed anything, I am happy to provide it. Many thanks in advance for any help or pointers on this. Regards, Tony Pearce

2 4

[cinder] monthly video meeting poll results
by Brian Rosmaita 11 Jul '20

11 Jul '20

tl;dr - our first video meeting will be Wednesday 29 July connection info will be on the agenda etherpad, https://etherpad.opendev.org/p/cinder-victoria-meetings For those who didn't see the poll, this is what it was about: We're considering holding the Cinder weekly meeting as a video conference once each month. It will be the last meeting of each month and will take place at the regularly scheduled meeting time (1400 UTC for 60 minutes). Video Meeting Rules: * 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. The results: Do it? - 50% in favor, 33% in strong favor, 17% don't care, no one opposed. Record? - 50% yes, 50% don't care Conferencing software? - Bluejeans: first choice of 70% of respondents Comments - Let's work hard to write what we speak! - people who don't want to be recorded can turn their camera off - video conference plus IRC is for sure better than IRC only - Zoom is shady and possibly not appropriate for an open source project that wants to welcome contributors from all countries. I think we're better off avoiding it. Conclusion: We'll hold the Cinder weekly meeting for 29 July in BlueJeans *and* IRC following the ground rules laid out above, and continue doing the same for the last meeting of each month through the end of the Victoria cycle. The meetings will be recorded.

2 1

[kolla] PTL holiday
by Mark Goddard 11 Jul '20

11 Jul '20

Hi, I will be on holiday next Tuesday (14th) to Thursday (16th). I will therefore miss both the IRC meeting and Kolla Klub. If someone is able to chair the IRC meeting, please reply here. There is currently nothing on the agenda for the Klub, so anyone looking to chair that meeting will also need to find some topics to cover. We have suggestions in [1]. Cheers, Mark [1] https://docs.google.com/document/d/1EwQs2GXF-EvJZamEx9vQAOSDB5tCjsDCJyHQN5_…

2 1

[loci][helm][k8s] When do images on docker.io get updated
by info＠dantalion.nl 10 Jul '20

10 Jul '20

Hello, the images on docker.io have last been updated 9 months ago https://hub.docker.com/u/loci, I was wondering when do they get updated? As I am currently waiting for the image for Watcher to be available, this image has recently been added as gate job. I require this image in order for the OpenStack helm charts to test https://review.opendev.org/#/c/720140/. Kind regards, Corne lukken

2 2

[blazar] IRC meetings cancelled next week
by Pierre Riteau 10 Jul '20

10 Jul '20

Hello, As I will be on holiday next week (July 13-17), I have proposed that both IRC meetings are cancelled. We will meet again on Tuesday July 21 for EMEA and Thursday July 30 for Americas. Cheers, Pierre (priteau)

1 0

OpenStack cluster event notification
by Anil Jangam 10 Jul '20

10 Jul '20

Hi All, So far, based on my understanding of OpenStack Python SDK, I am able to read the Hypervisor, Servers instances, however, I do not see an API to receive and handle the change notification/events for the operations that happens on the cluster e.g. A new VM is added, an existing VM is deleted etc. I see a documentation, which talks about emitting notifications over a message bus that indicate different events that occur within the service. Notifications in OpenStack <https://docs.openstack.org/ironic/latest/admin/notifications.html> https://docs.openstack.org/ironic/latest/admin/notifications.html 1. Does Openstack Python SDK support notification APIs? 2. How do I receive/monitor notifications for VM related changes? 3. How do I receive/monitor notifications for compute/hypervisor related changes? 4. How do I receive/monitor notifications for Virtual Switch related changes? Thanks in advance for any help in this regard. /anil.

3 4

[all][InteropWG] weekly Friday call - request for Partciapation
by prakash RAMCHANDRAN 10 Jul '20

10 Jul '20

Hi all, We have the agenda listed on https://etherpad.opendev.org/p/interop Call is now moved to meetpad and will be easy to acess and try it out today in next 10-15 minutes if you find time and interest. OpenStack / Open Infra -interopWGInterop Working Group - Weekly Friday 10-11 AM or UTC 17-18 Lnink: https://meetpad.opendev.org/Interop-WG-weekly-meeting ThanksPrakash

1 0

[release] Release countdown for week R-13 July 13 - July 17
by Sean McGinnis 10 Jul '20

10 Jul '20

Development Focus ----------------- The Victoria-2 milestone will happen in a few weeks, on July 30. Victoria-related specs should now be finalized so that teams can move to implementation ASAP. Some teams observe specific deadlines on the second milestone (mostly spec freezes): please refer to https://releases.openstack.org/victoria/schedule.html for details. General Information ------------------- Please remember that libraries need to be released at least once per milestone period. At milestone 2, the release team will propose releases for any library that has not been otherwise released since milestone 1. Other non-library deliverables that follow the cycle-with-intermediary release model should have an intermediary release before milestone-2. Those who haven't will be proposed to switch to the cycle-with-rc model, which is more suited to deliverables that are released only once per cycle. At milestone-2 we also freeze the contents of the final release. If you have a new deliverable that should be included in the final release, you should make sure it has a deliverable file in: https://opendev.org/openstack/releases/src/branch/master/deliverables/victo… You should request a beta release (or intermediary release) for those new deliverables by milestone-2. We understand some may not be quite ready for a full release yet, but if you have something minimally viable to get released it would be good to do a 0.x release to exercise the release tooling for your deliverables. See the MembershipFreeze description for more details: https://releases.openstack.org/victoria/schedule.html#v-mf Finally, now may be a good time for teams to check on any stable releases that need to be done for your deliverables. If you have bugfixes that have been backported, but no stable release getting those. If you are unsure what is out there committed but not released, in the openstack/releases repo, running the command "tools/list_stable_unreleased_changes.sh <cycle_name>" gives a nice report. Upcoming Deadlines & Dates -------------------------- Victoria-2 milestone: July 30

1 0

[neutron] Team meeting - day change proposal
by Slawek Kaplonski 10 Jul '20

10 Jul '20

Hi, During our last Monday team meeting I proposed to cancel this bi-weekly Monday meeting and have weekly meeting on Tuesday always. It is officially proposed in https://review.opendev.org/#/c/739780/ - if You usually attends those meetings and You didn’t check it yet, please do and give +1 if You are ok with such change. Thx in advance. — Slawek Kaplonski Principal software engineer Red Hat

1 0

Neutron Agent Migration
by Johannes Scheuermann 10 Jul '20

10 Jul '20

Hi together, currently we exploring how we can reboot a compute node without any interruptions for the networking stack. We run Openstack Train with ml2 driver Linux bridge and dnsmasq for DHCP and internal DNS. The DHCP setup runs as high availability setup with 3 replicas. During our tests we identified the following challenges: 1.) If we reboot the machine without doing anything on the network layer all ports will be rescheduled. Also the networks will be removed from the (dead) agent and will be reassigned to another agent. But for each reboot we have some leftover ports with the device-id "reserved_dhcp_port". These ports can safely deleted (we haven't figured out where the issue in the neutron code is). 2.) If we disable the network agent like described here: https://docs.openstack.org/neutron/train/admin/config-dhcp-ha.html and then remove the disabled agent from all networks we have an even worse behaviour since the neutron scheduler doesn't reschedule the network to a different agent. So what is the correct way to ensure that the reboot of a node has no (or only small) interruptions to the networking service? The current issue is that if we remove one agent we might remove the port that is the first entry in the clients (VM's) resolv.conf which means that each request will be delayed by the default timeout. And is there any option to "migrate" a network from one agent to another? Thanks in advance, Johannes Scheuermann

2 1

[manila][stable] moving some stable branches to EOL
by Goutham Pacha Ravi 09 Jul '20

09 Jul '20

Hello Stackers, There have been no changes to the stable/ocata [1], driverfixes/mitaka [2], driverfixes/newton [3] and driverfixes/ocata [4] branches of openstack/manila in a year [1] and the manila team today decided [2] that it was time to close this branches. While we routinely get requests from users, vendors and distributions to backport bug fixes to older releases, no one seems to want any further changes in these branches. We'd also like stable/pike to be EOL'ed, the last change to that branch was a CVE fix made three months ago. Keeping these branches open may give the impression that we'd continue to take backports in, and support them with bugfixes, when the reality is that we're struggling to keep meaningful testing in stable/queens and stable/rocky branches - something we've seen most bugfix/backport requests for. If there are no objections, I'll propose an EOL patch and request the infra team to help delete these branches. Thanks, Goutham [1] https://opendev.org/openstack/manila/commits/branch/stable/ocata [2] https://opendev.org/openstack/manila/src/branch/driverfixes/mitaka [3] https://opendev.org/openstack/manila/src/branch/driverfixes/newton [4] https://opendev.org/openstack/manila/src/branch/driverfixes/ocata [2] http://eavesdrop.openstack.org/meetings/manila/2020/manila.2020-07-09-15.01…

1 0

[cyborg] Temporary treatment plan for the 3rd-party driver
by Brin Zhang(张百林) 09 Jul '20

09 Jul '20

Hi all： This release we want to introduce some 3rd party drivers (e.g. Intel QAT, Inspur FPGA, and Inspur SSD etc.) in Cyborg, and we discussed the handling of 3rd-party driver CI in Cyborg IRC meeting [1]. Due to the lack of CI test environment supported by hardware, we reached a temporary solution in two ways, as follows: 1. Provide a CI environment and provide a tempest test for Cyborg, this method is recommended; 2. If there is no CI environment, please provide the test results of this driver in the master branch or in the designated branch, which should be as complete as possible, sent to the Cyborg team, or pasted in the implementation of the commit. [1] http://eavesdrop.openstack.org/meetings/openstack_cyborg/2020/openstack_cyb…

1 0

RDO - ModuleNotFoundError: No module named 'cinder.volume.drivers.glusterfs'
by lejeczek 09 Jul '20

09 Jul '20

Hi guys, I've packstaked a deployment with: CONFIG_CINDER_BACKEND=gluster CONFIG_CINDER_VOLUMES_CREATE=y CONFIG_CINDER_GLUSTER_MOUNTS=127.0.0.1:/VMs But after seemingly all work okey I keep getting: 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume Traceback (most recent call last): 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume File "/usr/lib/python3.6/site-packages/cinder/cmd/volume.py", line 103, in _launch_service 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume cluster=cluster) 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume File "/usr/lib/python3.6/site-packages/cinder/service.py", line 400, in create 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume cluster=cluster, **kwargs) 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume File "/usr/lib/python3.6/site-packages/cinder/service.py", line 155, in __init__ 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume *args, **kwargs) 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume File "/usr/lib/python3.6/site-packages/cinder/volume/manager.py", line 267, in __init__ 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume active_backend_id=curr_active_backend_id) 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume File "/usr/lib/python3.6/site-packages/oslo_utils/importutils.py", line 44, in import_object 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume return import_class(import_str)(*args, **kwargs) 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume File "/usr/lib/python3.6/site-packages/oslo_utils/importutils.py", line 30, in import_class 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume __import__(mod_str) 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume ModuleNotFoundError: No module named 'cinder.volume.drivers.glusterfs' 2020-07-09 16:18:03.157 2547017 ERROR cinder.cmd.volume ... I'm Centos 8 with "ussuri". Would you know & share a solution? many thanks, L.

3 2

[kolla] Today is the first Kall
by Radosław Piliszek 09 Jul '20

09 Jul '20

Hiya Folks, today (09 Jul) is the first Kolla's Kall [1]. It starts at 15:00 UTC so in just a bit less than half an hour. (Sorry for the late reminder, these days don't spare me.) Today's agenda is based on one of the top priorities for Victoria - DA DOCS. We decided to give Meetpad a try. It does not record meetings but we will document the meeting on etherpad anyhow. The link is on the referenced wiki page. (The potential fallback will be Google Meet, we will update the wiki). Everyone is free to join. Kolla Kall is development-oriented and focuses on implementation discussion, change planning, release planning, housekeeping, etc. The expected audience is people interested in Kolla projects development, including Kolla, Kolla-Ansible and Kayobe. Looking forward to seeing YOU there. [1] https://wiki.openstack.org/wiki/Meetings/Kolla/Kall -yoctozepto

1 1

Hardware requirement for OpenStack HA Cluster
by Anil Jangam 09 Jul '20

09 Jul '20

Hi All, I am looking for hardware requirements (CPU, RAM, HDD) for installing a OpenStack HA cluster. So far, I gathered few references: - This article talks about CPU and HDD, but they do not comment on RAM. - https://docs.openstack.org/project-deploy-guide/openstack-ansible/ocata/ove… - This article talks about CPU, RAM, and HDD, but it is quite old (2015) reference. - https://docs.huihoo.com/openstack/docs.openstack.org/ha-guide/HAGuide.pdf (Page 6) I am considering the cluster with: 3 Controller (for HA) + 1 Compute + 1 Storage. I have following questions: - What is the minimum hardware (CPU, RAM, HDD) requirement to install a OpenStack HA cluster? - Can we have 3 Controller nodes installed on 3 Virtual Machines or do we need 3 independent (bare metal) servers? - So in case of VM-based controllers, the cluster will be hybrid in nature. - I do not know if this is even possible and a recommended design. - Do we need the Platform Director node in addition to controller and compute/storage nodes? Thanks in advance. Anil.

2 1

[All][Neutron][Devstack] OVN as the Default Devstack Neutron Backend
by Slawek Kaplonski 09 Jul '20

09 Jul '20

Hi, The Neutron team wants to propose a switch of the default Neutron backend in Devstack from OVS (neutron-ovs-agent, neutron-dhcp-agent, neutron-l3-agent) to OVN with its own ovn-metadata-agent and ovn-controller. We discussed that change during the virtual PTG - see [1]. In this document we want to explain reasons why we want to do that change. OVN in 75 Words --------------- Open Virtual Network is managed under the OVS project, and was created by the original authors of OVS. It is an attempt to re-do the ML2/OVS control plane, using lessons learned throughout the years. It is intended to be used in projects such as OpenStack and Kubernetes. OVN has a different architecture, moving us away from Python agents communicating with the Neutron API service via RabbitMQ to C daemons communicating via OpenFlow and OVSDB. Here’s a heap of information about OpenStack’s integration of OVN: * OpenStack Boston Summit talk on OVN [2] * Upstream OpenStack networking-ovn documentation [3] and [4] * OSP 13 OVN documentation, including how to install it using Director [5] Neutron OVN driver was developed as a Neutron stadium project, "networking-ovn". In the Ussuri cycle, networking-ovn was merged into the main Neutron repository. Why? ---- In the Neutron team we believe that OVN and the Neutron OVN driver are built with a modern architecture that offers better foundations for a simpler and more performant solution. We see increased participation in kubernetes-ovn, resulting in a larger core OVN community, and we would like OpenStack to benefit from this Kubernetes driven OVN investment. Neutron OVN driver currently has got some feature parity gaps comparing to ML2/OVS (see [6] for details) but our team is working hard to close those gaps and we believe that this driver is the future for Neutron and that’s why we want to make it the default Neutron ML2 backend in the Devstack configuration. What Does it Mean? ------------------ Since most Openstack projects use Neutron in their CI and gate jobs, this change has the potential for a large impact. But this backend is already tested with various jobs in the Neutron CI and it works fine. Recently (See [7]) we also proposed to add an OVN based job to the Devstack’s check queue. Similarly the default Neutron backend in TripleO was changed in the Stein cycle and there were no any significant issues related strictly to this change. It worked well for other projects. Of course in the Neutron project we will be still gating other drivers, like ML2/Linuxbridge and ML2/OVS - nothing will change here, except for the names of some of the jobs. The Neutron team is *NOT* going to deprecate any of the other existing ML2 drivers. We will be still maintaining Linuxbridge, OVS and other in-tree drivers in the same way as it is now. Action Plan ----------- We want to make this change before the Victoria-2 milestone to not make such changes too late in the release cycle. Our action plan is as below: 1. Share the plan and get feedback from the upstream community (this thread) 2. Move OVN related Devstack code from a plugin defined in the Neutron repo to Devstack repo - we don’t want to force everyone else to add “enable_plugin neutron” in their local.conf file to use default Neutron backend, 3. Switch default Neutron backend in Devstack to be OVN, a. Switch definition of base devstack CI jobs that it will run Neutron with OVN backend, 4. Propose DNM patches depend on patch from point 3 and 3a to main OpenStack projects to check if it will not break anything in the gate of those projects. 5. If all will be running fine, merge patches proposed in points 3 and 3a. [1] https://etherpad.opendev.org/p/neutron-victoria-ptg - Lines 185 - 193 [2] https://www.youtube.com/watch?v=sgc7myiX6ts [3] https://docs.openstack.org/neutron/latest/admin/ovn/index.html [4] https://docs.openstack.org/neutron/latest/ovn/index.html [5] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13… [6] https://docs.openstack.org/neutron/latest/ovn/gaps.html [7] https://review.opendev.org/#/c/736021/ -- Slawek Kaplonski Senior software engineer Red Hat

6 8

[neutron] Drivers meeting - agenda for 10.07.2020
by Slawek Kaplonski 09 Jul '20

09 Jul '20

Hi, For tomorrow’s meeting we have 2 RFEs to discuss: https://bugs.launchpad.net/neutron/+bug/1886798 - [RFE] Port NUMA affinity policy - this one was already discussed briefly few weeks ago - see http://eavesdrop.openstack.org/meetings/neutron_drivers/2020/neutron_driver… - but now as Rodolfo proposed official RFE, lets talk again about it, https://bugs.launchpad.net/neutron/+bug/1880532 - [RFE]L3 Router should support ECMP - this one was also discussed some time ago, owner of the rfe provided some additional info recently so please take a look into that and we will also discuss that tomorrow. Have a great day and see You on tomorrow’s meeting :) — Slawek Kaplonski Principal software engineer Red Hat

1 0

[neutron] PTL on vacation
by Slawek Kaplonski 09 Jul '20

09 Jul '20

Hi, For the next 2 weeks, starting Saturday 11th of July I will be on vacation without access to the irc and with very limited access to the email. Miguel Lavalle will run our team meetings during this time. With other things You can always ask one of our drivers [1] or lieutenants [1] https://review.opendev.org/#/admin/groups/464,members [2] https://docs.openstack.org/neutron/latest/contributor/policies/neutron-team… — Slawek Kaplonski Principal software engineer Red Hat

1 0

[Cinder]
by Marek Lyčka 09 Jul '20

09 Jul '20

Hi all, I'm currently looking into extending Nova API to allow on-demand VM quiescing with the ultimate goal being improved Cinder snapshot creation. The spec is undergoing review at the moment and I was wondering if someone from Cinder would be kind enough to look it over and give their thoughts on it: https://review.opendev.org/#/c/702810/ Thanks in advance. -- Marek Lyčka Linux Developer Ultimum Technologies a.s. Na Poříčí 1047/26, 11000 Praha 1 Czech Republic marek.lycka(a)ultimum.io <stanislav.ulrych(a)ultimum.io> *https://ultimum.io <https://ultimum.io/>*

2 1

July OSF Community Meeting - 10 Years of OpenStack
by Sunny Cai 08 Jul '20

08 Jul '20

Hello everyone, You might have heard that OpenStack is turning 10 this year! On Thursday, July 16 at 8am PT (1500 UTC), we will be holding the 10 years of OpenStack virtual celebration in the July OSF community meeting. I have attached the calendar invite for the July OSF community meeting below. Grab your favorite OpenStack swag and bring your favorite drinks of choice to the meeting on July 16. Let’s do a virtual toast to the 10 incredible years! Please see the etherpad for more meeting information: https://etherpad.opendev.org/p/tTP9ilsAaJ2E8vMnm6uV <https://etherpad.opendev.org/p/tTP9ilsAaJ2E8vMnm6uV> If you have any questions, please let me know. P.S. To add more fun, feel free to try out the virtual background feature in Zoom. The 10 years of OpenStack virtual background is attached below. Thanks, Sunny Cai OpenStack Foundation sunny(a)openstack.org <mailto:sunny@openstack.org>

1 0

[neutron][lbaas][octavia] How to implement health check using 100.64.0.0/10 network segments in loadbalancer?
by Zhengyu Pan 08 Jul '20

08 Jul '20

There are some private cloud or public cloud introduction: They use 100.64.0.0/14 network segments to check vm's health status in load balancer. In Region supporting VPC, load balancing private network IP and health check IP will be switched to 100 network segment. I can't understand how to implement it. How to do it? --

2 1

[tripleo] updating the language we use in our code base
by Wesley Hayutin 08 Jul '20

08 Jul '20

Greetings, At this moment in time we have an opportunity to be a more open and inclusive project by eliminating outdated naming conventions from our code base [1]. We should take the opportunity and do our best to replace outdated terms with their more inclusive alternatives. Chris Wright wrote a nice blog post on the subject [2], please take a second to review Bogdan's spec and Chris's blog post. Also a thank you to Emilien, Alex and Bogdan for already getting started. In other news Arx Cruz will be starting a similar thread for the tempest project. Thanks Arx! [1] https://review.opendev.org/#/c/740013/1/specs/victoria/renaming_rules.rst [2] https://www.redhat.com/en/blog/making-open-source-more-inclusive-eradicatin… Patches to be aware of: https://review.opendev.org/#/c/738858/ https://review.opendev.org/#/c/738894/ <https://review.opendev.org/#/c/738894/1> https://review.opendev.org/#/c/740013 Thanks for your time!

1 0

[Neutron] GRE network MTU
by Budai Laszlo 08 Jul '20

08 Jul '20

Dear all, what is the maximum MTU value for a GRE network? How is that related to the physical interfaces' MTU? Thank you, Laszlo

1 0

[largescale-sig] Next meeting: July 8, 8utc
by Thierry Carrez 08 Jul '20

08 Jul '20

Hi everyone, Hot on the heels of the OpenDev event on Large scale deployments, the Large Scale SIG will have a meeting this week on Wednesday, July 8 at 8 UTC[1] in the #openstack-meeting-3 channel on IRC: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200708T08 Feel free to add topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting A reminder of the TODOs we had from last meeting, in case you have time to make progress on them: - amorin to add some meat to the wiki page before we push the Nova doc patch further - all to describe briefly how you solved metrics/billing in your deployment in https://etherpad.openstack.org/p/large-scale-sig-documentation - ttx to produce a draft of the 10th birthday slide for the SIG Talk to you all on Wednesday, -- Thierry Carrez

1 1

[ironic] 2nd Victoria meetup
by Dmitry Tantsur 07 Jul '20

07 Jul '20

Hi all, Since we're switching to 6 releases per year cadence, I think it makes sense to have short virtual meetups after every release. The goal will be to sync on priorities, exchange ideas and define plans for the upcoming 2 months of development. Fooling around is also welcome! Please vote for the best 2 hours slot next week: https://doodle.com/poll/3r9tbhmniattkty8. I tried to include more potential time zones, so apologies for so many options. Please cast your vote until Friday, 12pm UTC, so that I can announce the final time slot this week. Dmitry

2 4

[keystone][zun] Choice between 'ca_file' and 'cafile'
by Hongbin Lu 07 Jul '20

07 Jul '20

Hi all, A short question. I saw a few projects are using the name 'ca_file' [1] as config option, while others are using 'cafile' [2]. I wonder what is the flavorite name convention? I asked this question because Kolla developer suggested Zun to rename from 'ca_file' to 'cafile' to avoid the confusion [3]. I want to confirm if this is a good idea from Keystone's perspective. Thanks. Best regards, Hongbin [1] http://codesearch.openstack.org/?q=cfg.StrOpt%5C(%27ca_file%27&i=nope&files… [2] http://codesearch.openstack.org/?q=cfg.StrOpt%5C(%27cafile%27&i=nope&files=… [3] https://review.opendev.org/#/c/738329/

4 3

[openstack-helm] Proposing Andrii Ostapenko for core of OpenStack-Helm
by Gage Hugo 07 Jul '20

07 Jul '20

Hello everyone, Andrii Ostapenko (andrii_ostapenko) has been very active lately in the openstack-helm community, notably his efforts in driving loci forward as well as him maintaining a lot of our images and providing great in-depth reviews. Due to these reasons, I am proposing Andrii as a core reviewer for OpenStack-Helm. If anyone has any feedback, please feel free to reply here by the end of the week!

1 0

[nova] Changes for out-of-tree drivers
by Stephen Finucane 07 Jul '20

07 Jul '20

I have a change proposed [1] as part of the work to add vTPM support to nova that will modify the arguments for the 'unrescue' function. As noted in the commit message, this is expected to gain a 'context' argument and lose the currently unused 'network_info' argument. If you maintain an out-of-tree driver, you will need to account for this change. Cheers, Stephen [1] https://review.opendev.org/#/c/730382/

1 0

[glance] Global Request ID issues in Glance
by Markus Hentsch 07 Jul '20

07 Jul '20

Hello everyone, while I was experimenting with the Global Request ID functionality of OpenStack [1], I identified two issues in Glance related to this topic. I have written my findings below and would appreciate it if you could take a look and confirm whether those are intended behaviors or indeed issues with the implementation. In case of the latter please advice me which bug tracker to report them to. 1. The Glance client does not correctly forward the global ID When the SessionClient class is used, the global_request_id is removed from kwargs in the constructor using pop() [2]. Directly after this, the parent constructor is called using super(), which in this case is Adapter from the keystoneauth1 library. Therein the global_request_id is set again [3] but since it has been removed from the kwargs, it defaults to None as specified in the Adapter's __init__() header. Thus, the global_request_id passed to the SessionClient constructor never actually makes it to the Glance API. This is in contrast to the HTTPClient class, where get() is used instead of pop() [4]. This can be reproduced simply by creating a server in Nova from an image in Glance, which will attempt to create the Glance client instance using the global_request_id [5]. Passing the "X-Openstack-Request-Id" header during the initial API call for the server creation, makes it visible in Nova (using a suitable "logging_context_format_string" setting) but it's not visible in Glance. Using a Python debugger shows Glance generating a new local ID instead. 2. Glance interprets global ID as local one for Oslo Context objects While observing the Glance log file, I observed Glance always logging the global_request_id instead of a local one if it is available. Using "%(global_request_id)s" within "logging_context_format_string"[6] in the glance-api.conf will always print "None" in the logs whereas "%(request_id)s" will either be an ID generated by Glance if no global ID is available or the received global ID. Culprit seems to be the context middleware of Glance where the global ID in form of the "X-Openstack-Request-Id" header is parsed from the request and passed as "request_id" instead of "global_request_id" to the "glance.context.RequestContext.from_environ()" call [7]. This is in contrast to other services such as Nova or Neutron where the two variables actually print the values according to their name (request_id always being the local one, whereas global_request_id is the global one or None). [1] https://specs.openstack.org/openstack/oslo-specs/specs/pike/global-req-id.h… [2] https://github.com/openstack/python-glanceclient/blob/de178ac4382716cc93022… [3] https://github.com/openstack/keystoneauth/blob/dab8e1057ae8bb9a0e778fb8d314… [4] https://github.com/openstack/python-glanceclient/blob/de178ac4382716cc93022… [5] https://github.com/openstack/nova/blob/1cae0cd7229207478b70275509aecd778ca6… [6] https://docs.openstack.org/oslo.context/2.17.0/user/usage.html#context-vari… [7] https://github.com/openstack/glance/blob/e6db0b10a703037f754007bef6f5645108… Thanks! Markus -- Markus Hentsch Team Leader secustack GmbH - Digital Sovereignty in the Cloud https://www.secustack.com Königsbrücker Straße 96 (Gebäude 30) | 01099 Dresden District Court Dresden, Register Number: HRB 38890

2 2

[nova][stable] The openstack/nova stable/pike branch is currently unmaintained
by Lee Yarwood 06 Jul '20

06 Jul '20

Hello all, Following on from my recent mail about the stable/ocata branch of the openstack/nova project now being unmaintained [1] I'd also like to move the stable/pike [2] branch formally into this phase of maintenance [3]. Volunteers are welcome to step forward and attempt to move the branch back to the ``Extended Maintenance`` phase by proposing changes and fixing CI in the next 3 months, otherwise the branch will be marked as ``EOL`` [4]. Again hopefully this isn't taking anyone by surprise but please let me know if this is going to be an issue! Regards, [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-July/015747.html [2] https://review.opendev.org/#/q/project:openstack/nova+branch:stable/pike [3] https://docs.openstack.org/project-team-guide/stable-branches.html#unmainta… [4] https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-l… -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76

2 2

removing use of pkg_resources to improve command line app performance
by Doug Hellmann 06 Jul '20

06 Jul '20

We have had a long-standing issue with the performance of the openstack command line tool. At least part of the startup cost is the time taken in scanning for all of the plugins that are installed, which is a side-effect of importing pkg_resources. To fix that, we need to eliminate all use of pkg_resources in code that would be used by a command line application (long-running services are candidates, too, but the benefit is bigger in short-lived command line apps). Python 3.8 added a new library importlib.metadata, which also has an entry points API. It is more efficient, and produces data in a format that can be cached to make it even faster. I have started adding support for that caching to stevedore [0], which is the Oslo library for managing application plugins. For version of python earlier than 3.8, the same library is available on PyPI as “importlib_metadata”. A big part of the implementation work will actually be removing the use of pkg_resources in places other than stevedore. We have a couple of different use patterns to consider and replace in different ways. First, anything using iter_entry_points() should use a stevedore extension manager instead. There are a few of them to choose from, based on how the plugins will be used. The stevedore docs [1] include a tutorial and documentation for all of the classes and their uses. Most calls to iter_entry_points() can be replaced with a stevedore.ExtensionManager directly, but the other managers are meant to implement common access patterns like selecting a subset (or just one) of the available plugins by name. Second, we have a few places where pkg_resources.get_distribution(name).version is used to discover a package’s installed version. Those can be changed to use importlib.metadata.version() instead, as in [2]. This is *much* faster because importlib goes directly to the metadata file for the named package instead of looking through all of the installed packages. Finally, any code using any properties of the EntryPoint returned by stevedore other than “name” and “load()” may need to be updated. The new EntryPoint class in importlib.metadata is not 100% compatible with the one from pkg_resources. The same data is there, but sometimes it is named differently. If we need a compatibility layer we could put that in stevedore, but it is unusual to need access to any of the internals of EntryPoint and it’s typically better to use the manager abstractions in stevedore instead of manipulating EntryPoint instances directly. I have started making some of the changes [3], but I’m doing this in my quarantine-induced spare time so it’s likely to take a while. If you want to pitch in, I would appreciate it. I am using the topic “osc-performance”, since the work is related to making python-openstackclient faster. Feel free to tag me for reviews on your patches. Doug [0] https://review.opendev.org/#/c/739306/ [1] https://docs.openstack.org/stevedore/latest/ [2] https://review.opendev.org/#/c/739379/2 [3] https://review.opendev.org/#/q/topic:osc-performance

4 8

[tc] weekly update
by Mohammed Naser 06 Jul '20

06 Jul '20

Hi everyone, Here’s an update for what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. We've also included a few references to some important mailing list threads that you should check out. # Patches ## Open Review - Cleanup the remaining osf repos and their data https://review.opendev.org/739291 - Update goal selection docs to clarify the goal count https://review.opendev.org/739150 - Add legacy repository validation https://review.opendev.org/737559 - Add "tc:approved-release" tag to manila https://review.opendev.org/738105 - Create starter-kit:kubernetes-in-virt tag https://review.opendev.org/736369 - [draft] Add assert:supports-standalone https://review.opendev.org/722399 ## Project Updates - Add deprecated cycle for deprecated deliverables https://review.opendev.org/737590 - No longer track refstack repos in governance https://review.opendev.org/737962 - Add Neutron Arista plugin charm to OpenStack charms https://review.opendev.org/737734 ## General Changes - Add links to chosen release names https://review.opendev.org/738867 - Add storyboard link to migrate-to-focal goal https://review.opendev.org/738129 - TC Guide Follow Ups https://review.opendev.org/737650 # Email Threads - New Office Hours: http://lists.openstack.org/pipermail/openstack-discuss/2020-July/015761.html - OSU Intern Work: http://lists.openstack.org/pipermail/openstack-discuss/2020-July/015760.html - Summit Programming Committee Nominations Open: http://lists.openstack.org/pipermail/openstack-discuss/2020-July/015756.html - Summit CFP Open: http://lists.openstack.org/pipermail/openstack-discuss/2020-July/015730.html # Other Reminders - OpenStack's 10th anniversary community meeting should be happening July 16th: more info coming soon! - If you're an operator, make sure you fill out our user survey: https://www.openstack.org/user-survey/survey-2020/ Thanks for reading! Mohammed & Kendall -- Mohammed Naser VEXXHOST, Inc.

1 0

Re: [rdo-users] [rdo][ussuri][TripleO][nova][kvm] libvirt.libvirtError: internal error: process exited while connecting to monitor
by Arkady Shtempler 06 Jul '20

06 Jul '20

Hi all! I was able to analyze the attached log files and I hope that the results may help you understand what's going wrong with instance creation. You can find *Log_Tool's unique exported Error blocks* here: http://paste.openstack.org/show/795356/ *Some statistics and problematical messages:* ##### Statistics - Number of Errors/Warnings per Standard OSP log since: 2020-06-30 12:30:00 ##### Total_Number_Of_Errors --> 9 /home/ashtempl/Ruslanas/controller/neutron/server.log --> 1 /home/ashtempl/Ruslanas/compute/stdouts/ovn_controller.log --> 1 /home/ashtempl/Ruslanas/compute/nova/nova-compute.log --> 7 *nova-compute.log* *default default] Error launching a defined domain with XML: <domain type='kvm'>* 368-2020-06-30 12:30:10.815 7 *ERROR* nova.compute.manager [req-87bef18f-ad3d-4147-a1b3-196b5b64b688 7bdb8c3bf8004f98aae1b16d938ac09b 69134106b56941698e58c61... 70dc50f] Instance *failed* to spawn: *libvirt.libvirtError*: internal *error*: qemu unexpectedly closed the monitor: 2020-06-30T10:30:10.182675Z qemu-kvm: *error*: failed to set MSR 0... he monitor: 2020-06-30T10:30:10.182675Z *qemu-kvm: error: failed to set MSR 0x48e to 0xfff9fffe04006172* _msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' *failed*. [instance: 128f372c-cb2e-47d9-b1bf-ce17270dc50f] *Traceback* (most recent call last): 375-2020-06-30 12:30:10.815 7* ERROR* nova.compute.manager [instance: 128f372c-cb2e-47d9-b1bf-ce17270dc50f] File "/usr/lib/python3.6/site-packages/nova/vir... *server.log * 5821c815-d213-498d-9394-fe25c6849918', 'status': 'failed', *'code': 422} returned with failed status* *ovn_controller.log* 272-2020-06-30T12:30:10.126079625+02:00 stderr F 2020-06-30T10:30:10Z|00247|patch|WARN|*Bridge 'br-ex' not found for network 'datacentre'* Thanks! On Tue, Jun 30, 2020 at 2:13 PM Ruslanas Gžibovskis <ruslanas(a)lpic.lt> wrote: > attaching logs here. let's see if it will work. > > On Tue, 30 Jun 2020 at 12:55, Ruslanas Gžibovskis <ruslanas(a)lpic.lt> > wrote: > >> hi all, >> >> I am back, had some issues with MTU. >> Now looks good, at least deployment part. >> >> So I have installed back what I had, and still failing at same point as >> in first message. >> >> I have tried to use: LogTool, how to use it? well, I launched it, but it >> always say [0] detailed output: >> File "./PyTool.py", line 596, in <module> >> random_node=random.choice(overcloud_nodes) >> >> I do not get, how to make it work, should it get from stackrc ? as I see >> in >> overcloud_nodes = [] >> all_nodes = exec_command_line_command('source ' + source_rc_file_path >> + 'stackrc;openstack server list -f json')[ >> >> [0] http://paste.openstack.org/show/795345/ >> >> On Wed, 24 Jun 2020 at 20:02, Arkady Shtempler <ashtempl(a)redhat.com> >> wrote: >> >>> Hi Ruslanas! >>> >>> Is it possible to get all logs under /var/log/containers somehow? >>> >>> Thanks! >>> >>> On Wed, Jun 24, 2020 at 2:18 AM Ruslanas Gžibovskis <ruslanas(a)lpic.lt> >>> wrote: >>> >>>> Hi Alfredo, >>>> >>>> Compute nodes are baremetal or virtualized?, I've seen similar bug >>>>>> reports when using nested virtualization in other OSes. >>>>>> >>>>> baremetal. Dell R630 if to be VERY precise. >>>> >>>> >>>> >>>>>> When using podman, the recommended way to restart containers is using >>>>> systemd: >>>>> >>>>> >>>>> https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deploym… >>>>> >>>> >>>> Thank you, I will try. I also modified a file, and it looked like it >>>> relaunched podman container once config was changed. Either way, if I >>>> understand Linux config correctly, the default value for user and group is >>>> root, if commented out: >>>> #user = "root" >>>> #group = "root" >>>> >>>> also in some logs, I saw, that it detected, that it is not AMD CPU :) >>>> and it is really not AMD CPU. >>>> >>>> >>>> Just for fun, it might be important, here is how my node info looks. >>>> ComputeS01Parameters: >>>> NovaReservedHostMemory: 16384 >>>> KernelArgs: "crashkernel=no rhgb" >>>> ComputeS01ExtraConfig: >>>> nova::cpu_allocation_ratio: 4.0 >>>> nova::compute::libvirt::rx_queue_size: 1024 >>>> nova::compute::libvirt::tx_queue_size: 1024 >>>> nova::compute::resume_guests_state_on_host_boot: true >>>> _______________________________________________ >>>> users mailing list >>>> users(a)lists.rdoproject.org >>>> http://lists.rdoproject.org/mailman/listinfo/users >>>> >>>> To unsubscribe: users-unsubscribe(a)lists.rdoproject.org >>>> >>> >> >> -- >> Ruslanas Gžibovskis >> +370 6030 7030 >> > > > -- > Ruslanas Gžibovskis > +370 6030 7030 >

4 10

[python-openstackclient] microversion support
by jayaditya gupta 06 Jul '20

06 Jul '20

Hi , we discussed the microversion support in PTG meeting .I would like to get started with it. How can I help with this? Currently OpenStack CLI is defaulting to nova api V2, we want to change it so it takes latest version. for issue reference see this : https://storyboard.openstack.org/#!/story/2007727 Best Regards Jayaditya Gupta

1 0

[All][Neutron] Migrate old DB migration versions to init ops
by Rodolfo Alonso Hernandez 06 Jul '20

06 Jul '20

Hello all: Along this years we have increased the number of DB migrations each time we needed a new DB schema. This is good because that means the project is evolving and adding new features. Although this is not a problem per se, there are some inconvenients: - Every time a system is deployed (for example in the CI using devstack), the initial DB schema is created. Then, each migration is applied sequentially. - Some FT tests are still checking the sanity of some migrations [1] implemented a few releases ago. - We are still testing the contract DB migrations. Of course, this is something supported before and we still need to apply those revisions. - "TestWalkMigrationsMysql" and "TestModelsMigrationsMysql", both using MySQL backend, are still affected by LP#1687027. The proposal is to remove some DB migrations, starting from Liberty; of course, because all migrations must be applied in a specific order, we should begin from the initial revision, "kilo". The latest migration to be removed should be decided depending on the stable releases support. Apart from mitigating or solving some of the commented problems, we can "group" the DB model definition in one place. E.g.: "subnetpools" table is created in "other_extensions_init_ops". This file contains the first table. However is modified in at least two migrations: - 1b4c6e320f79_address_scope_support_in_subnetpool: added "address_scope_id" field - 13cfb89f881a_add_is_default_to_subnetpool: added "is_default" field Instead of having (at least) three places where the "subnetpools" DB schema is defined, we can remove the Mitaka migration and group this definition in just one place. One possible issue: some migrations add dependencies on other tables. That means the table the dependency is referring should be created in advance. That implies that, in some cases, the table creation order should be modified. That should never affect subsequent created tables or migrations. Do you see any inconvenience on this proposal? Am I missing something that I didn't consider? Thank you and regards. [1] https://github.com/openstack/neutron/blob/9fd60ffaac6b178de62dab169c826d52f…

4 6

[cyborg] Incomplete v2 API in Train
by Ildiko Vancsa 05 Jul '20

05 Jul '20

Hi Cyborg Team, I’m working with the CNTT community[1], they are working on building reference architecture for telecom workloads. Cyborg is important for their work to be able to utilize hardware acceleration resources. We are planning to use the Train version of OpenStack projects including Cyborg and it would be great to be able to switch to the v2 API as v1 is deprecated now. If my understanding is correct the v2 API implementation in Train is partial, but the documentation[2] doesn’t give accurate view about what is included. The CNTT team would like to be able to integrate and access the whole v2 API if that is possible. It would be great to discuss the options that we could use on the way forward. Would it be possible to bring this up and discuss on an upcoming Cyborg team meeting? Thanks, Ildikó [1] https://www.lfnetworking.org/about/cntt/ [2] https://docs.openstack.org/cyborg/train/api/api.html#v2-0

2 2

Re: [cyborg] Incomplete v2 API in Train
by yumeng bao 05 Jul '20

05 Jul '20

Hi Ildikó, > Hi Cyborg Team, > I’m working with the CNTT community[1], they are working on building reference architecture for telecom workloads. Cyborg is important for their work to be able to utilize hardware acceleration > resources. > We are planning to use the Train version of OpenStack projects including Cyborg and it would be great to be able to switch to the v2 API as v1 is deprecated now. If my understanding is correct > the v2 API implementation in Train is partial, but the documentation[2] doesn’t give accurate view about what is included. Yes,your understanding is correct,the v2 API implementation in Train is partial. I would update the documentation soon. I would recommend you to use the stable/ussuri version(instead of train release) of cyborg for two reasons: 1) API V2 in ussuri is complete while that of train is incomplete 2)the nova-cyborg integration[3] was not landed until Ussuri[4],so the integration in Train is also partial[5]. So if CNTT wants the complete accelerator management function,it would be better to use cyborg ussuri. > The CNTT team would like to be able to integrate and access the whole v2 API if that is possible. It would be great to discuss the options that we could use on the way forward. Would it be > possible to bring this up and discuss on an upcoming Cyborg team meeting? Yes, sure. We can bring this up on the next weekly meeting on this Thursday 03:00 UTC at #openstack-cyborg, I have added this to meeting agenda[6]. > Thanks, > Ildikó > [1] https://www.lfnetworking.org/about/cntt/ > [2] https://docs.openstack.org/cyborg/train/api/api.html#v2-0 [3]https://specs.openstack.org/openstack/nova-specs/specs/ussuri/implemented… [4]https://releases.openstack.org/ussuri/highlights.html#cyborg [5]https://releases.openstack.org/train/highlights.html#cyborg [6]https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting#Agenda Regards， Yumeng

2 1

[Neutron] Bug Deputy Report (June 29 - July 05)
by Hongbin Lu 05 Jul '20

05 Jul '20

Hi all, Below is the bug deputy report for last week. Critical: * https://bugs.launchpad.net/neutron/+bug/1885900 test_trunk_subport_lifecycle is failing in ovn based jobs * https://bugs.launchpad.net/neutron/+bug/1885899 test_qos_basic_and_update test is failing High: * https://bugs.launchpad.net/neutron/+bug/1886116 slaac no longer works on IPv6 tenant subnets * https://bugs.launchpad.net/neutron/+bug/1885898 test connectivity through 2 routers fails in neutron-ovn-tempest-full-multinode-ovs-master job * https://bugs.launchpad.net/neutron/+bug/1885897 Tempest test_create_router_set_gateway_with_fixed_ip test is failing often in dvr scenario job * https://bugs.launchpad.net/neutron/+bug/1885695 [OVS] "vsctl" implementation does not allow empty transactions Medium: * https://bugs.launchpad.net/neutron/+bug/1885891 DB exception when updating a "ml2_port_bindings" object * https://bugs.launchpad.net/neutron/+bug/1885758 RPCMessage timeouts when ovs agent is reporting status about many ports Low: * https://bugs.launchpad.net/neutron/+bug/1886216 keepalived-state-change does not format correctly the logs * https://bugs.launchpad.net/neutron/+bug/1885547 [fullstack] OVS interface events isolation error with more than one OVS agent RFE: * https://bugs.launchpad.net/neutron/+bug/1885921 [RFE][floatingip port_forwarding] Add port ranges

1 0

[all][tc][goals] Migrate CI/CD jobs to new Ubuntu LTS Focal: Week R-15 Update
by Ghanshyam Mann 05 Jul '20

05 Jul '20

Hello Everyone, Please find the week R-15 updates on 'Ubuntu Focal migration' community goal. Tracking: https://storyboard.openstack.org/#!/story/2007865 Progress: ======= * I have prepared the patched to migrate the unit/functional/doc/cover tox jobs to focal which are WIP till we finish the project side testing. This and its base patches - https://review.opendev.org/#/c/738328/ * devstack and tempest base patches are changed with Depends-On on 738328 tox job patch. This way we can test the complete gate (integration + unit +functional + doc + cover +pep8 + lower-constraint) jobs with a single testing patch by doing Depends-On: https://review.opendev.org/#/c/734700/ (or devstack base patch or tox one if you do not have tempest jobs to test) * I have started a few more project testing and found bugs on the incompatible deps versions for Focal. Please refer to the 'Bugs Report' section for details. Bugs Report: ========== Summary: Total 4 (1 fixed, 3 in-progress). 1. Bug#1882521. (IN-PROGRESS) There is open bug for nova/cinder where three tempest tests are failing for volume detach operation. There is no clear root cause found yet -https://bugs.launchpad.net/cinder/+bug/1882521 We have skipped the tests in tempest base patch to proceed with the other projects testing but this is blocking things for the migration. 2. We encountered the nodeset name conflict with x/tobiko. (FIXED) nodeset conflict is resolved now and devstack provides all focal nodes now. 3. Bug#1886296. (IN-PROGRESS) pyflakes till 2.1.0 is not compatible with python 3.8 which is the default python version on ubuntu focal[1]. With pep8 job running on focal faces the issue and fail. We need to bump the pyflakes to 2.1.1 as min version to run pep8 jobs on py3.8. As of now, many projects are using old hacking version so I am explicitly adding pyflakes>=2.1.1 on the project side[2] but for the long term easy maintenance, I am doing it in 'hacking' requirements.txt[3] nd will release a new hacking version. After that project can move to new hacking and do not need to maintain pyflakes version compatibility. 4. Bug#1886298. (IN-PROGRESS) 'Markupsafe' 1.0 is not compatible with the latest version of setuptools[4], We need to bump the lower-constraint for Markupsafe to 1.1.1 to make it work. There are a few more issues[5] with lower-constraint jobs which I am debugging. What work to be done on the project side: ================================ This goal is more of testing the jobs on focal and fixing bugs if any otherwise migrate jobs by switching the nodeset to focal node sets defined in devstack. 1. Start a patch in your repo by making depends-on on either of below: devstack base patch if you are using only devstack base jobs not tempest: https://review.opendev.org/#/c/731207/ OR tempest base patch if you are using the tempest base job (like devstack-tempest): https://review.opendev.org/#/c/734700/ Example: https://review.opendev.org/#/c/738126/ 2. If none of your project jobs override the nodeset then above patch will be testing patch(do not merge) otherwise change the nodeset to focal. Example: https://review.opendev.org/#/c/737370/ 3. If the jobs are defined in branchless repo and override the nodeset then you need to override the branches variant to adjust the nodeset so that those jobs run on Focal on victoria onwards only. If no nodeset is overridden then devstack being branched and stable base job using bionic/xenial will take care of this. Once we finish the testing on projects side and no failure then we will merge the devstack and tempest base patches. Important things to note: =================== * Do not forgot to add the story and task link to your patch so that we can track it smoothly. * Use gerrit topic 'migrate-to-focal' * Do not backport any of the patches. References: ========= Goal doc: https://governance.openstack.org/tc/goals/selected/victoria/migrate-ci-cd-j… Storyboard tracking: https://storyboard.openstack.org/#!/story/2007865 [1] https://github.com/PyCQA/pyflakes/issues/367 [2] https://review.opendev.org/#/c/739315/ [3] https://review.opendev.org/#/c/739334/ [4] https://github.com/pallets/markupsafe/issues/116 [5] https://zuul.opendev.org/t/openstack/build/7ecd9cf100194bc99b3b70fa1e6de032 -gmann

1 0

Re: [loci][helm][k8s] When do images on docker.io get updated
by Andrii Ostapenko 03 Jul '20

03 Jul '20

Hello Corne, OSH uses images built using gates in openstack/openstack-helm-images repository, not in loci itself. You may want to add a definition for watcher image similar to [0] and then refer to it in the corresponding release job, e.g. for Stein [1]. After your commit to openstack-helm-images is merged, new images will be published to docker.io/openstackhelm/watcher repository and can be used in the way you referenced them in your OSH commit [2]. [0] https://opendev.org/openstack/openstack-helm-images/src/branch/master/zuul.… [1] https://opendev.org/openstack/openstack-helm-images/src/branch/master/zuul.… [2] https://review.opendev.org/#/c/720140/

3 2

[TC] Monthly Meeting Summary
by Mohammed Naser 03 Jul '20

03 Jul '20

Hi everyone, Here’s a summary of what happened in our TC monthly meeting last Thursday, July 2nd. # ATTENDEES (LINES SAID) - mnaser (106) - gmann (43) - evrardjp (32) - diablo_rojo (32) - njohnston (11) - jungleboyj (8) - openstack (7) - ricolin (6) - fungi (4) - ttx (2) - clarkb (2) - belmoreira (1) - knikolla (1) - AJaeger (1) # MEETING SUMMARY - Rollcall (mnaser, 14:00:40) - Follow up on past action items (mnaser, 14:04:59) - OpenStack Foundation OSU Intern Project (diablo_rojo) (mnaser, 14:26:55) - W cycle goal selection start (mnaser, 14:36:02) - https://governance.openstack.org/tc/goals/#goal-selection-schedule (gmann, 14:37:37) - Completion of retirement cleanup (gmann) (mnaser, 14:48:36) - https://etherpad.opendev.org/p/tc-retirement-cleanup is a scratch pad; nothing pushed out towards the community (mnaser, 14:48:59) # ACTION ITEMS - evrardjp & njohnston to start writing resolution about how deconstructed PTL role - mnaser to find the owner to start using facing API pop-up team over ML - gmann update goal selection docs to clarify the goal count - gmann start discussion around reviewing currenet tags - mnaser propose change to implement weekly meetings - diablo_rojo start discussion on ML around potential items for OSF funded intern - njohnston and mugsie to work on getting goals groomed/proposed for W cycle - TC and community to help finish properly and cleanly retiring projects To read the full logs of the meeting, please refer to http://eavesdrop.openstack.org/meetings/tc/2020/tc.2020-07-02-14.00.log.html. -- Mohammed Naser VEXXHOST, Inc.

1 0

[TC] [all] OSU Intern Work
by Kendall Nelson 03 Jul '20

03 Jul '20

Hello! As you may or may not know, the OSF funded a student at Oregon State University last year to work on OpenStack part time. He did a lot of amazing work on Glance but sadly we are coming to the end of his internship as he will be graduating soon. I'm happy to report that we have the budget to fund another student part time to work on OpenStack again and I wanted to collect suggestions of projects/areas that a student could be helpful in. It is important to note, that they will only be working part time and, while I will be helping to mentor them, I will likely need a co-mentor in the area/topic to help me get them going, get their patches reviewed, answer questions as they go etc. Originally, I had thought about assigning them to Glance (like this past year) or Designate (like we had considered last year), but now I am thinking the User Facing API work (OpenStackSDK/OSC/et al) might be a better fit? If you are interested in helping mentor a student in any of those areas or have a better idea I am all ears :) I look forward to your suggestions. -Kendall (diablo_rojo)

2 3

[Telemetry] Error when sending to prometheus pushgateway
by Samuel Mutel 03 Jul '20

03 Jul '20

Hello, I have two questions about ceilometer (openstack version rocky). - First of all, it seems that ceilometer is sending metrics every hour and I don't understand why. - Next, I am not able to setup ceilometer to send metrics to prometheus pushgateway. Here is my configuration: > sources: > - name: meter_file > interval: 30 > meters: > - "*" > sinks: > - prometheus > > sinks: > - name: prometheus > publishers: > - prometheus://10.60.4.11:9091/metrics/job/ceilometer > Here is the error I received: > vcpus{resource_id="7fab268b-ca7c-4692-a103-af4a69f817e4"} 2 > # TYPE memory gauge > memory{resource_id="7fab268b-ca7c-4692-a103-af4a69f817e4"} 2048 > # TYPE disk.ephemeral.size gauge > disk.ephemeral.size{resource_id="7fab268b-ca7c-4692-a103-af4a69f817e4"} 0 > # TYPE disk.root.size gauge > disk.root.size{resource_id="7fab268b-ca7c-4692-a103-af4a69f817e4"} 0 > : HTTPError: 400 Client Error: Bad Request for url: > http://10.60.4.11:9091/metrics/job/ceilometer > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http Traceback > (most recent call last): > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http File > "/usr/lib/python2.7/dist-packages/ceilometer/publisher/http.py", line 178, > in _do_post > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http > res.raise_for_status() > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http File > "/usr/lib/python2.7/dist-packages/requests/models.py", line 935, in > raise_for_status > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http raise > HTTPError(http_error_msg, response=self) > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http HTTPError: > 400 Client Error: Bad Request for url: > http://10.60.4.11:9091/metrics/job/ceilometer > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http > Thanks for your help on this topic.

2 1

[Telemetry] Propose Matthias Runge for Telemetry core
by Rong Zhu 03 Jul '20

03 Jul '20

Hello all, Matthias Runge have been very active in the repository with patches and reviews. So I would like to propose adding Matthias as core developer for the telemetry project. Please, feel free to add your votes into the thread. -- Thanks, Rong Zhu

3 3

[oslo] PTO on Monday
by Ben Nemec 03 Jul '20

03 Jul '20

Hi Oslo, I'm making this a four day weekend (Friday is a US holiday), so I won't be around for the meeting on Monday. If someone else wants to run it then feel free to hold it without me. Otherwise we'll return to the regular schedule the following week. -Ben

2 1

[neutron] Drivers meeting agenda - 03.07.2020
by Slawek Kaplonski 03 Jul '20

03 Jul '20

Hi, For tomorrows drivers meeting we have 1 RFE to discuss: https://bugs.launchpad.net/neutron/+bug/1885921 - [RFE][floatingip port_forwarding] Add port ranges See You all on the meeting tomorrow. — Slawek Kaplonski Senior software engineer Red Hat

2 2

[Diversity] Diversity & Inclusion WG Meeting 7/6
by Amy Marrich 02 Jul '20

02 Jul '20

The Diversity & Inclusion WG invites members of all OSF projects to our next meeting Monday, July 6th, at 17:00 UTC in the #openstack-diversity channel. The agenda can be found at https://etherpad.openstack.org/p/diversity -wg-agenda. We will be discussing changing our Wiki page to reflect the broader OSF projects and communities so that the page reflects our mission. Please feel free to add any other topics you wish to discuss at the meeting. Thanks, Amy (spotz)

1 0

[2020 Summit] Programming Committee Nominations Open
by Ashlee Ferguson 02 Jul '20

02 Jul '20

Programming Committee nominations for the 2020 Open Infrastructure Summit are open! Programming Committees for each Track will help build the Summit schedule, and are made up of individuals working in open infrastructure. Responsibilities include: • Help the Summit team put together the best possible content based on your subject matter expertise • Promote the individual Tracks within your networks • Review the submissions and Community voting results in your particular Track • Determine if there are any major content gaps in your Track, and if so, potentially solicit additional speakers directly to submit • Ensure diversity of speakers and companies represented in your Track • Avoid vendor sales pitches, focusing more on real-world user stories and technical, in-the-trenches experiences 2020 Summit Tracks: • 5G, NFV & Edge • AI, Machine Learning & HPC • CI/CD • Container Infrastructure • Getting Started • Hands-on Workshops • Open Development • Private & Hybrid Cloud • Public Cloud • Security If you’re interested in nominating yourself or someone else to be a member of the Summit Programming Committee for a specific Track, please fill out the nomination form[1]. Nominations will close on July 10, 2020. NOMINATION FORM[1] Programming Committee selections will occur before we open the Call for Presentations (CFP) to receive presentations so that the Committees can host office hours to consult on submissions, and help promote the event. The CFP will be open July 1 - August 4, 2020. Please email speakersupport(a)openstack.org with any questions or feedback. Cheers, Ashlee [1] https://openstackfoundation.formstack.com/forms/programmingcommitteenom_sum… Ashlee Ferguson Community & Events Coordinator OpenStack Foundation

1 1

[glance] Weekly review priorities
by Abhishek Kekane 02 Jul '20

02 Jul '20

Hi Team, We are 3 weeks away from the Victoria milestone 2 release and already our review stack is increasing day by day. We need to get below important specs reviewed and merged in the next couple of weeks. Also we need some reviews on backports as well as important fixes. I have sorted down some patches which need reviews for this week. Specs: 1. sparse image upload - https://review.opendev.org/733157 2. Unified limits - https://review.opendev.org/729187 3. Image encryption - https://review.opendev.org/609667 4. Cinder store multiple stores support - https://review.opendev.org/695152 5. Duplicated image downloads - https://review.opendev.org/734683 6. Add copy-unowned-image spec https://review.opendev.org/739062 Backports: 1. Add lock per share for cinder nfs mount/umount - https://review.opendev.org/#/c/726650/ (stable/train) 2. Add lock per share for cinder nfs mount/umount - https://review.opendev.org/#/c/726914/ (stable/ussuri) 3. zuul: switch to the "plain" grenade job here too - https://review.opendev.org/739056 4. Use grenade-multinode instead of the custom legacy job - https://review.opendev.org/738693 Bug fixes on master: 1. Add image_set_property_atomic() helper - https://review.opendev.org/737868 2. Fix race condition in copy image operation - https://review.opendev.org/737596 3. Don't include plugins on 'copy-image' import - https://review.opendev.org/738675 4. Fix: Interrupted copy-image leaking data on subsequent operation - https://review.opendev.org/737867 Cleanup patches: 1. Removal of 'enable_v2_api' - https://review.opendev.org/#/c/738672/ (review dependency chain as well) Happy reviewing!! Abhishek

1 0

[nova][stable] The openstack/nova stable/ocata branch is currently unmaintained
by Lee Yarwood 02 Jul '20

02 Jul '20

Hello all, A quick note to highlight that the stable/ocata branch of openstack/nova [1] is formally in the ``Unmaintained`` [2] phase of maintenance will be moved on to the final ``EOL`` phase after a total of 6 months of inactivity. I'm going to suggest that we ignore the following change as this only attempted to remove a job from the experimental queue and doesn't constitute actual maintenance of the branch IMHO. Remove exp legacy-tempest-dsvm-full-devstack-plugin-nfs https://review.opendev.org/#/c/714958/ As a result I consider the branch to have been inactive for 3 of the required 6 months before it can be marked as ``EOL`` [3]. Volunteers are welcome to step forward and attempt to move the branch back to the ``Extended Maintenance`` phase by proposing changes and fixing CI in the next 3 months, otherwise the branch will be marked as ``EOL``. Hopefully this isn't taking anyone by surprise but please let me know if this is going to be an issue! Regards, [1] https://review.opendev.org/#/q/project:openstack/nova+branch:stable/ocata [2] https://docs.openstack.org/project-team-guide/stable-branches.html#unmainta… [3] https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-l… -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76

2 1

[all][stable] Moving the stable/ocata to 'Unmaintained' phase and then EOL
by Ghanshyam Mann 02 Jul '20

02 Jul '20

Hello Everyone, Ocata is in the 'Extended Maintenance' phase[1] but its gate is broken and difficult to fix now. The main issue started for gate is about Tempest and its deps constraint is correctly used on Ocata or not. We fixed most of those issues when things started failing during py2 drop[2]. But now things are broken due to newer stestr is installed in Ocata jobs[2]. As Sean also mentioned in this backport[4] that stestr is not constraint in Ocata[5] as it was not in g-r that time so cannot be added in u-c. Tempest old tag cannot be fixed to have that with cap on the tempest side. The only option left to unblock the gate is to remove the integration testing from Ocata gate. But it will untested after that as we cannot say unit testing is enough to mark it tested. At least from QA perspective, I would not say it is tested if there is no integration job running there. Keeping it untested (no integration testing) and saying it is Maintained in the community can be very confusing things. I think its time to move it to the 'Unmaintained' phase and then EOL. Thought? [1] https://releases.openstack.org/ [2] https://review.opendev.org/#/q/topic:fix-stable-gate+(status:open+OR+status… [3] https://zuul.opendev.org/t/openstack/build/e477d0919ff14eea9cd8a6235ea00c3d… [4] https://review.opendev.org/#/c/726931/ [5] https://opendev.org/openstack/requirements/src/branch/stable/ocata/upper-co… -gmann

8 12

[tripleo][update][blueprint] Update refactor: more feedback, more control, more speed.
by Sofer Athlan-Guyot 02 Jul '20

02 Jul '20

Hi, hope you liked the title, I find it catchy. Update is mainly an afterthought that needs to work. So we mainly fix "stuff" there. No major change happened there since a long time. Following the PTG, I'm proposing a new blueprint and a bug: 1. Refactor tripleo update to offer the user more feedback and control[1]. 2. Registering node and repos can happen after some module check for packages[2]. I'm pretty new to this so I would need feedback about the form and content. For instance, point 2. could be a blueprint instead of a bug, tell me what you think. 1. refactor update step to load step playbook instead of looping over the steps: - this will speed up update (no more skipped tasks) - this will offer point of recovery when the update fails (by doing something like in named debug[3] for deployment) 2. refactor/fix? host-prep-tasks to include two steps: - step0 to add pre-update in-flight validation to the update process and rhosp registration; - step1 to all other tasks; - make sure it run in parallel on all nodes Point 1. would be a catch up with deployment. It offers speed improvement as we wouldn't skip tasks anymore. We could notify the user of what we are doing: "I'm removing the node from the cluster" instead of "step1". It would offer the user the hook to be able to restart a failed update from any step. Overall a big win, I think. Point 2. is newer, I filled it as a bug because I bumped into it as an issue when trying to add validation for subscription. It opens some possibilities for the update: - in-flight validation at the beginning of the update process that would be skipped during deployment using tag - using tags we could also run specific day 2 action outside of the update window: openstack overcloud update run --tags 'pre-update-validation' (with pre-update-validation in host-prep-tasks step0) openstack overcloud update run --tags 'rhsm-subscription' Well, it looked promising to me. Now, tell me what you think, but please, be nice, I'm old and susceptible. I have more coming, sorted by order of though I put into it, starting with the ones I though about more: - Check if we need a reboot of the server and notify the user. - Gain some more speed and clarity by having a running-on-all-host-in-parallel-host-update-prep-tasks new step. For instance all HA image tagging magic could go in there. - Investigate converge and check if we still could not further optimize it for update. I would like to gain more experience with the process before I filled those new blueprints. I'm going to draft a spec for the proposed blueprint and then I'll push some WIP code. Thanks, [1] https://blueprints.launchpad.net/tripleo/+spec/tripleo-update-smart-steps [2] https://bugs.launchpad.net/tripleo/+bug/1886028 [1] https://review.opendev.org/#/c/636731/ -- Sofer Athlan-Guyot chem on #irc DFG:Upgrades

1 0

[tripleo][ci] status RED
by Wesley Hayutin 01 Jul '20

01 Jul '20

Greetings, Unfortunately both check and gate are RED atm due to [1]. The issue w/ CirrOS-5.1 was fixed / reverted over the weekend [2]. I expect the check and gate jobs to continue to be RED for the next few days as the investigation proceeds. I would encourage folks to only workflow patches that are critical as the chances you will actually merge anything is not great. [1] https://bugs.launchpad.net/tripleo/+bug/1885286 [2] https://review.opendev.org/#/c/738025/

1 2

[cinder] spec freeze now in effect
by Brian Rosmaita 01 Jul '20

01 Jul '20

The Cinder spec freeze is now in effect. Here is the rundown on how the specs that have not yet been accepted for Victoria stand: The following specs have a spec freeze exception. Specs must be merged by 1600 UTC on 10 July. (Ideally, you'll have your revisions completed before next week's Cinder meeting on 8 July so we can discuss any issues at the meeting and give you time in case you need to make a final revision.) Remove quota usage cache https://review.opendev.org/#/c/730701/ - need to address some comments on the spec Support modern compression algorithms in cinder backup https://review.opendev.org/#/c/726307/ - needs a requirements change analysis; see comments on the review Reset state robustification https://review.opendev.org/#/c/682456/ - just needs to make moving the "force" option to cinder-manage explicit Default volume type overrides https://review.opendev.org/#/c/733555/ - need some tiem to work out the REST API change more carefully The following spec has been rejected for Victoria, but the team is OK with this being clarified (suggestions are in the comments on the review) and proposed for Wallaby: Support revert any snapshot to the volume https://review.opendev.org/#/c/736111/ The following spec has been rejected for Victoria, but because it's really a bug: volume list query optimization https://review.opendev.org/#/c/726070/ - it's been turned into https://bugs.launchpad.net/cinder/+bug/1885961 and the proposer can submit patches that address the bug. cheers, brian

1 0

[all][summit][cfp] 2020 Open Infrastructure Summit Call for Presentations Open!
by Ashlee Ferguson 01 Jul '20

01 Jul '20

We’re excited to announce that the Call for Presentations [1] for the 2020 Open Infrastructure Summit is now open until August 4! During the Summit, you’ll be able to join the people building and operating open infrastructure. Submit sessions featuring projects including Airship, Ansible, Ceph, Kata Containers, Kubernetes, ONAP, OpenStack, OPNFV, StarlingX and Zuul! 2020 Tracks • 5G, NFV & Edge • AI, Machine Learning & HPC • CI/CD • Container Infrastructure • Getting Started • Hands-on Workshops • Open Development • Private & Hybrid Cloud • Public Cloud • Security Types of sessions Presentations; demos encouraged Panel Discussions Lightning Talks If your talk is not selected for the official track schedule, we may reach out to have you present it as a Lightning Talk during the Summit in a shorter 10-15 minute format SUBMIT YOUR PRESENTATION [1] - Deadline August 4, 2020 Summit CFP is only for presentation, panel, and workshop submissions. The content submission process for the Forum and Project Teams Gathering (PTG) will be managed separately in the upcoming months. Programming Committee nominations are also now open. The Programming Committee helps select sessions from the CFP for the Summit schedule. Nominate yourself or or someone else for the Programming Committee [2] before July 10, 2020 and help us program the Summit! Registration and sponsorship coming soon! For sponsorship inquiries, please email kendall(a)openstack.org <mailto:kendall@openstack.org>. Please email speakersupport(a)openstack.org with any CFP questions or feedback. Thanks, Ashlee [1] cfp.openstack.org [2] https://openstackfoundation.formstack.com/forms/programmingcommitteenom_sum… <https://openstackfoundation.formstack.com/forms/programmingcommitteenom_sum…> Ashlee Ferguson Community & Events Coordinator OpenStack Foundation

1 0

[CEILOMETER] Error when sending to prometheus pushgateway
by Samuel Mutel 01 Jul '20

01 Jul '20

Hello, I have two questions about ceilometer (openstack version rocky). - First of all, it seems that ceilometer is sending metrics every hour and I don't understand why. - Next, I am not able to setup ceilometer to send metrics to prometheus pushgateway. Here is my configuration: > sources: > - name: meter_file > interval: 30 > meters: > - "*" > sinks: > - prometheus > > sinks: > - name: prometheus > publishers: > - prometheus://10.60.4.11:9091/metrics/job/ceilometer > Here is the error I received: > vcpus{resource_id="7fab268b-ca7c-4692-a103-af4a69f817e4"} 2 > # TYPE memory gauge > memory{resource_id="7fab268b-ca7c-4692-a103-af4a69f817e4"} 2048 > # TYPE disk.ephemeral.size gauge > disk.ephemeral.size{resource_id="7fab268b-ca7c-4692-a103-af4a69f817e4"} 0 > # TYPE disk.root.size gauge > disk.root.size{resource_id="7fab268b-ca7c-4692-a103-af4a69f817e4"} 0 > : HTTPError: 400 Client Error: Bad Request for url: > http://10.60.4.11:9091/metrics/job/ceilometer > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http Traceback > (most recent call last): > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http File > "/usr/lib/python2.7/dist-packages/ceilometer/publisher/http.py", line 178, > in _do_post > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http > res.raise_for_status() > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http File > "/usr/lib/python2.7/dist-packages/requests/models.py", line 935, in > raise_for_status > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http raise > HTTPError(http_error_msg, response=self) > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http HTTPError: > 400 Client Error: Bad Request for url: > http://10.60.4.11:9091/metrics/job/ceilometer > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http > Thanks for you help on this topic.

1 0

[scientific-sig] No IRC meeting today
by Stig Telfer 01 Jul '20

01 Jul '20

Hi All - Unfortunately I am not available to help with today’s Scientific SIG IRC meeting. However, if you haven’t done so already I recommend signing up for the OpenDev virtual event - https://www.openstack.org/events/opendev-2020/ - today it’s bare metal and edge use cases. The last two days have been very useful sessions. Cheers, Stig

1 0

[neutron][drivers] Propose Rodolfo Alonso Hernandez for Neutron drivers team
by Slawek Kaplonski 01 Jul '20

01 Jul '20

Hi, Rodolfo is very active Neutron contributor since long time. He has wide knowledge about all or almost all areas of the Neutron and Neutron stadium projects. He is an expert e.g. in ovs agent, pyroute and privsep module, openvswitch firewall, db layer, OVO and probably many others. He also has very good understanding about Neutron project in general, about it's design and direction of development. Rodolfo is also active on our drivers meetings already and I think that his feedback about many things there is very good and valuable for the team. For all these reasons I think that he will be great addition to our drivers team. I will keep this nomination open for a week waiting for Your feedback and votes. -- Slawek Kaplonski Senior software engineer Red Hat

6 6