March 2019 - openstack-discuss - lists.openstack.org

[neutron] [designate] [kolla] dnsmasq internal resolver and instance hostnames
by Krzysztof Klimonda 13 Mar '19

13 Mar '19

Hi, I’m trying to wrap my head around how neutron, dnsmasq and resolving internal hostnames is supposed to be working. I have a lab deployment with pike where I want to enable designate service, and also have instances resolve their “siblings” using hostnames (the deployment is done using kolla if it matters). I’ve noticed that dnsmasq is not authorative for the domain set in `dns_domain` and sends all DNS requests up the chain - that seems to make instances unable to resolve their own name, and names of other instances in the same network. Is getting it to work as simple as adding `auth-zone=$dns_domain` to `/etc/neutron/dnsmasq.conf` or is there something more going on with my deployment, and that should just work? -Chris

1 0

[oslo] [rabbitmq] RabbitMQ and EPMD bound to ipv6 issue
by Gabriele Santomaggio 13 Mar '19

13 Mar '19

Hi all, Recently we had an issue with RabbitMQ and EPMD bound to ipv6. Here [1] you can find the discussion. Note that this issue happens **only** when: 1- epmd is bound only to ipv6 interface 2- there are no other ways to look up the hostname The problem [2] is more in Erlang than in RabbitMQ 1 - https://groups.google.com/d/msg/rabbitmq-users/mbsT8PSJTHQ/JKEwev3uBQAJ 2 - https://github.com/erlang/otp/pull/602 Regards -- Gabriele Santomaggio Cloud Developer @SUSE

1 0

[kolla] Let's switch to Python 3
by Marcin Juszkiewicz 13 Mar '19

13 Mar '19

Python 2 is going bye bye. Everyone knows that, lot of us ignores that. But we need to move on. Kolla has few patches to make use of Python3 based binary packages. One for Fedora [1], other for Ubuntu and Debian [2]. 1. https://review.openstack.org/624838 2. https://review.openstack.org/625298 But those patches are just tip of iceberg... # Types of images There are two types of images in Kolla: - binary - source ## Binaries state in distributions Binary ones are built from distribution packages. For RHEL/CentOS/OracleLinux is means RDO packages, for Ubuntu it is UCA and for Debian it is whatever is in distribution repositories. RDO ones are Python 2 based because there is no other version of Python in RHEL7 (I do not count EPEL or SCL). For Ubuntu we have a mix of Python 2 and Python 3 (from what I heard). Debian needs update to Buster (current 'testing', currently in soft freeze) and then we will get Python 3 packages (currently for Rocky). ### Pip issue On binary distributions we tend to use 'pip' from distribution packages. Which means 8.1.2 for CentOS:7, 9.0.1 for Ubuntu:bionic and 18.1 for Debian:buster. ## Source images In my opinion this type of images is most common during development cycle. Here we install Python and binaries from distribution repositories and then bootstrap latest 'pip' and use it to install all Python modules we need. For now those images are Python 2 based. # WIP plans for T cycle For T cycle we should move whatever possible to Python 3. Which means Debian:buster, Ubuntu:bionic and source images. No idea yet does it involves CentOS:7 source images as well as this would require us to use EPEL repository for Python 3. ## Always bootstrap pip Due to 'pip' issue we may need to bootstrap latest version in each type of images. This will give us simple 'pip' command in each image nevermind which version of Python is used. That saves us from dealing with "is it 'pip' or 'pip3' we need to use" thing. ## Create new variables There will be few different versions of Python in use: 2.7 (RHEL7 family), 3.6 (Ubuntu:bionic and RHEL7/EPEL), 3.7 (Debian:buster). As we tend to modify some files or need to know where Python modules are present. We may use values from 'sys.path' list for it or create 'python_path' (or similar) variable and set it per distribution/image_type. # Some kind of work items list 1. Move Debian to 'buster' release. https://review.openstack.org/612681 2. Bootstrap 'pip' in all image types. 3. Move source images to Python 3 (Debian, Ubuntu for sure, no idea yet about CentOS). 4. Move binary images to Python 3 (Debian, Ubuntu, Fedora/RHEL8) Each step will require several build/test/fix cycles. We also need to identify which images still require Python 2. # Summary I know that this mail looks a bit chaotic but I think that we need to discuss and plan what we need to do and how. And cooperate with external teams which provide binary packages (that's why Thomas and Haïkel are in Cc:). What do you think?

5 10

[scientific-sig] IRC Meeting today CANCELLED
by Stig Telfer 13 Mar '19

13 Mar '19

Hi All - Owing to a shortage of time and content we are cancelling today’s meeting. Apologies, Stig

1 0

[tripleo][openstack-ansible] collaboration on os_tempest role update XIV - Mar 13, 2019
by Chandan kumar 13 Mar '19

13 Mar '19

Hello, Here is the 13th update (Mar 06 to Mar 12, 2019) on collaboration on os_tempest[1] role between TripleO and OpenStack-Ansible projects. Highlights of the week: * docs for os_tempest role configuration added https://docs.openstack.org/openstack-ansible-os_tempest/latest/user/configu… * Now os_tempest role is less dependent on root user * How os_tempest job is defined in tripleo side docs added https://docs.openstack.org/tripleo-docs/latest/install/basic_deployment/os_… * python-tempestconf is gatted with os_temepst tripleo job * Tripleo can now collect os_tempest realted files at one place in user's home directory under tempest folder. http://logs.openstack.org/76/640976/5/check/tripleo-ci-centos-7-standalone-… Thanks to Arx, Martin Kopec, Marios, Sagi on docs help, tempest log collection, odyssey4me, jrosser on tempest vars cleanup & cloudnull, mnaser on other reviews. Things got merged: [os_tempest] * Create tempest related directories from ansible user - https://review.openstack.org/640005 * Remove tempest_image_dir_owner var - https://review.openstack.org/629419 * Document os_tempest configuration options - https://review.openstack.org/639147 [openstack-ansible] * Set tempest_image_dir to /opt/cache/files in openstack CI - https://review.openstack.org/641308 [python-tempestconf] * Add tripleo-ci-centos-7-standalone-os-tempest job - https://review.openstack.org/640992 [tripleo] * Add os_tempest documentation - https://review.openstack.org/#/c/640859/ * Collect os_tempest files from tempest directory - https://review.openstack.org/#/c/640976/ Things in Progress: [os_tempest] * Fix tempest_image_dir default var to user's home tempest-image dir - https://review.openstack.org/640742 * os_tempest dependencies: https://review.openstack.org/#/q/topic:ostempest_packaging+(status:open+OR+… [tripleo] * Adding tempest .txt files in collect-logs role - https://review.openstack.org/#/c/640358/ What next this week: * make tripleo os_tempest job voting * complete os_tempest dependencies * Some more docs addition on how to run os_tempest role locally with minimal vars. Here is the 13th update [2]. Have queries, Feel free to ping us on #tripleo or #openstack-ansible channel. Links: [1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest [2.] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003482.ht… Thanks, Chandan Kumar

1 0

[nova] [openstack-charms] [elections] 'Train' Release PTL Election Kickoff
by Kendall Nelson 12 Mar '19

12 Mar '19

Hello Everyone! Polls for PTL elections are now open and will remain open for you to cast your vote until Mar 19, 2019 23:45 UTC. We are having elections for Nova and OpenStack_Charms. If you are a Foundation individual member and had a commit in one of the program's projects[0] over the Feb 09, 2018 00:00 UTC - Feb 19, 2019 00:00 UTC timeframe (Rocky to Stein) then you are eligible to vote. You should find your email with a link to the Condorcet page to cast your vote in the inbox of your gerrit preferred email[1]. What to do if you don't see the email and have a commit in at least one of the programs having an election: * check the trash or spam folders of your gerrit Preferred Email address, in case it went into trash or spam * wait a bit and check again, in case your email server is a bit slow * find the sha of at least one commit from the program project repos[0] and email the election officials. If we can confirm that you are entitled to vote, we will add you to the voters list for the appropriate election. Our democratic process is important to the health of OpenStack, please exercise your right to vote! Candidate statements/platforms can be found linked to Candidate names on this page: https://governance.openstack.org/election/#train-ptl-candidates Happy voting, -Kendall Nelson (diablo_rojo) [0] The list of the program projects eligible for electoral status: https://git.openstack.org/cgit/openstack/governance/plain/reference/project… [1] Sign into review.openstack.org: Go to Settings > Contact Information. Look at the email listed as your Preferred Email. That is where the ballot has been sent.

1 0

[ptl][I18n][election] PTL Candidacy for Train
by Ian Y. Choi 12 Mar '19

12 Mar '19

Hello, I am writing to announce my PTL candidacy of I18n for Train release. I served the PTL role on Ocata and Pike cycle, and have been great memory with last three release cycles with Frank who did so wonderful PTL activities. During Train cycle, I would like to do and collaborate with team members: * Helping to continue previous nice work (e.g., translation checksite, user-survey translation) * Investigating with Zanata's health and possible alternatives [1] * Communicating with translators and language coordinators * Sharing the voice from OpenStack teams with I18n team * Clean handover to the next PTL or discussing with team's direction (e.g., to a working group) I want to add the fourth part - as Frank wrote non-candicacy [2], it would be so great if the project gets fresh air. I don't think I am the part of fresh air since I also stayed in I18n team a lot like Frank. But it seems that I18n team needs more transition and hand-over period for a new PTL, or more discussion with team members might be needed to think about our team's direction such as changing the team status from an official team to a working group. With many thanks, /Ian [1] https://www.redhat.com/archives/zanata-devel/2019-February/msg00000.html [2] http://lists.openstack.org/pipermail/openstack-i18n/2019-March/003367.html

1 0

[ironic][ceilometer] Does anyone use the sensor data collection?
by Julia Kreger 12 Mar '19

12 Mar '19

Greetings everyone, I've been pondering retooling the metrics collection design in ironic, and I'm extremely curious if anyone actually uses what is presently in ironic in terms of metrics collection integration with ceilometer. The events, if enabled, should be getting funneled under the event_type "hardware.ipmi.metrics.update". If your using it, please contact me off-list. Thanks, -Julia

1 0

[ptl][sdk][election] PTL Candidacy
by Monty Taylor 12 Mar '19

12 Mar '19

Hi everybody! I'd like to run for PTL of OpenStackSDK again. We've been angling for a 1.0 release for the last few cycles and still haven't gotten there. We haven't gotten there because as we continue to merge in the shade logic, we've been finding places where we need to make some fundamental changes to the model. For instance, we made all Resource objects also behave like dicts, so that shade methods could return Resource objects directly. In order to do that, we had to rename the 'update' method on Resource objects to 'commit', since dicts have an update method already. We're currently in the midst of moving a good amount of the shade logic into the Proxy layer, so that uploading an image via the shade api or the proxy api is using the same code. That will be ongoing but should mostly be non-disruptive. I believe we're close enough, and have enough of a co-gating relationship with openstackclient, that this next cycle we need to start the work of shifting openstackclient implemention to openstacksdk from the python clients. Doing this should help us shake out any last remaining model deficiencies. We managed to get several long-standing todo list items done this past cycle. Cinder v3 support landed. Finally. We're also microversioning the Ironic calls, and have a good framework in place to do so with the other services as needed. We got the FairSemaphore feature added to keystoneauth which lets us remove the TaskManager and instead rely on an applications existing concurrency mechanism to handle parallelism while retaining our ability to perform client-side rate limiting. This change was actually inspired by some issues we saw in the field with Nodepool and the extra overhead from the TaskManager thread pool, but should end up facilitating more efficient use of openstacksdk constructs in OpenStack services using eventlet or other non-thread based concurrency systems. We still need to overhaul the caching layer. But once TaskManager is out we should be in a better place to deal with that. I'm sure there will be more things to do too. There always are. In any case, I'd love to keep helping to pushing these rocks uphill. Thanks! Monty

1 0

[stable][EM] Extended Maintenace - Pike
by Elõd Illés 12 Mar '19

12 Mar '19

Hi, As we are nearing to Pike Extended Maintenance (release page [1] shows 2019-03-03 but most probably will happen after Stein release) I have generated the list of open changes and unreleased changes on *stable/pike* for the follows-policy tagged repositories [2] (that seems to have relevant changes). Maybe it is useful for teams, who are planning to do a final release on Pike before moving stable/pike branches to Extended Maintenance. [1] https://releases.openstack.org/ [2] https://etherpad.openstack.org/p/pike-final-release-before-em Thanks, Előd

1 0

[ptl][tripleo][election] PTL Candidacy
by Alex Schultz 12 Mar '19

12 Mar '19

I would like to nominate myself for the TripleO PTL role for the Train cycle. Having previously served as PTL during the Queens and Rocky cycle, I think we should focus on the same items as those cycles. We have done excellent work adding python3 support in TripleO. I would like us to return back to focusing on simplification and improving the user experience. * Simplifying the deployment process I believe we should spend time looking at what actions we can remove or reduce by automating them as part of the deployment process. Let's figure out if we can improve the default installation so that we don't have to specify so much. Additionally I would like to start investigating if we can remove some of the services we currently rely on in the undercloud as part of the deployment. * Reducing duplication and tech debt Continued cleanup after containerization by fully removing the baremetal deployment of services as possible. Cleaning up logging and error handling to improve operators ability to troubleshoot their installations. Thanks, Alex Schultz irc: mwhahaha

3 2

[ptg][openstack-ansible] ptg planning
by Mohammed Naser 12 Mar '19

12 Mar '19

Hi everyone, Just a heads up, we've got an etherpad going, please put your name down if you're attending and if there's any subjects you'd like to bring up. https://etherpad.openstack.org/p/osa-train-ptg Thanks Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

1 0

[api][neutron] tagging support when creating a resource
by Akihiro Motoki 12 Mar '19

12 Mar '19

Hi API-SIG, neutron and tagging-related folks, This email ask opinions on tagging when creating a resource. We received a feature request to support tagging when creating a resource [1]. Neutron supports bulk creation of resources but the current tagging API recommended by the API-SIG does not define tagging when creating a resource. As a result, if we want to create 100 ports with specific tags, we need 1 (bulk creation) +100 (taggins per resource) API calls. It sounds nice to me to support tagging when creating a resource to address the above problem. What in my mind is to specify 'tags' attribute in a body of POST request like: {'port': {'name': 'foo', 'network_id': <network-id>, 'tags': ['red', 'blue'] } } I don't know the reason why the current API-SIG recommended tagging API does not support this model. The current tagging API defines "tags" as a subresource. Is there any reason this model was adopted? Best Regards, Akihiro Motoki (irc: amotoki) [1] https://bugs.launchpad.net/neutron/+bug/1815933 [RFE] Allow bulk-tagging of resources [2] https://specs.openstack.org/openstack/api-wg/guidelines/tags.html

4 5

Re: [nova][dev][ops] can we get rid of 'project_only' in the DB layer?
by Alex Xu 12 Mar '19

12 Mar '19

sorry, I lost the ML address again. Alex Xu <soulxu(a)gmail.com> 于2019年3月12日周二下午10:55写道： > After review this patch https://review.openstack.org/630769, it probably > leads me get some memory back. > > The reason we don't support user based policy and pass the instance's > context as target is John and Sean mention that we don't have enough test > to ensure all the APIs work correctly for cross the tenant user request. > > Similar to the patch https://review.openstack.org/630769 try to fix, that > patch fix the case admin user to execute a shelve action on normal tenant > user. If we enable a tenant user to execute an action on another tenant's > server, that will extend the case of https://review.openstack.org/630769, > we need ensure it works for that case also. > > So hope I remember correctly, just note at here, in case I forget mention > that in the future. > > melanie witt <melwittt(a)gmail.com> 于2019年2月20日周三下午4:16写道： > >> On Tue, 19 Feb 2019 10:42:32 -0600, Matt Riedemann <mriedemos(a)gmail.com> >> wrote: >> > On 2/18/2019 8:22 PM, melanie witt wrote: >> >> Right, that is the proposal in this email. That we should remove >> >> project_only=True and let the API policy check handle whether or not >> the >> >> user from a different project is allowed to get the instance. >> Otherwise, >> >> users are not able to use policy to control the behavior because it is >> >> hard-coded in the database layer. >> > >> > I think this has always been the long-term goal and I remember a spec >> > from John about it [1] but having said that, the spec was fairly >> > complicated (to me at least) and sounds like there would be a fair bit >> > of auditing of the API code we'd need to do before we can remove the DB >> > API check, which means it's likely not something we can complete at this >> > point in Stein. >> > >> > For example, I think we have a lot of APIs that run the policy check on >> > the context (project_id and user_id) as the target before even pulling >> > the resource from the database, and the resource itself should be the >> > target, right? >> > >> > [1] https://review.openstack.org/#/c/433037/ >> >> Thanks for the link -- I hadn't seen this spec yet. >> >> Yes, Alex just pinged me in #openstack-nova and now I finally understand >> his point that I kept missing before. He tried a test with my WIP patch >> and a user from project A was able to 'nova show' an instance from >> project B, even though the policy was set to 'rule:admin_or_owner'. The >> reason is because when the instance project/user isn't passed as a >> target to the policy check, the policy check for the request context >> project_id won't do anything. There's nothing for it to compare >> project_id with. This is interesting because it makes me wonder, what >> does a policy check like that [2] do then? It will take more learning on >> my part about the policy system to understand it. >> >> -melanie >> >> [2] >> >> https://github.com/openstack/nova/blob/3548cf59217f62966a21ea65a8cb74460643… >> >> >> >> >>

1 0

[wsme][dev] WSME needs cores
by Chris Dent 12 Mar '19

12 Mar '19

Most of the people listed as cores for WSME [1] are either not very active in the community any more or not actively interested in maintaining WSME. I'm in the latter group and wish to stop paying attention to it (because I don't use it and neither do the projects that I work on). To do that, though, it would be good to be able to assign a few more cores who are from projects that _do_ use it so that there's a reasonable bench of people to attend to things that will need to be done to keep it happy. The following is an incomplete list of projects that import WSME. aodh blazar cloudkitty cyborg glance ironic magnum mistral mogan octavia qinling watcher (I considered putting all these in the subject header that would have been incredibly tedious and noisy.) Octavia has representation on WSME-core, but beyond that, it's not clear. If you are a part of one of these projects and interested, please let me know and we'll make something happen. Apart from security and bug maintenance, WSME is a bit out of date with regard to testing plans. It does already support Python3, but it currently only tests with Python 3.5. Let me know. Whatever the outcome of these discussions, I'll be removing myself from WSME core and taking "check in on WSME" from my recurring todo list by next Tuesday. Thanks for your attention. [1] https://review.openstack.org/#/admin/groups/202,members -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

3 3

[ptl][vitrage]election]
by Ifat Afek 12 Mar '19

12 Mar '19

Hi all, I would like to announce my candidacy to continue as Vitrage PTL for the Train release. I’ve been the PTL of Vitrage since the day it started and I'll be happy to continue leading it in the next six months. I think we've had a very successful Stein cycle. Our main features include: * New and simplified template language * Improved resource query APIs * New service list API * Integrations with more openstack components (Trove, Zaqar, Monasca) * More flexible configuration for the Prometheus datasource Moving forward, these are the areas that I believe we should focus on: * Continue the cross-project work that we started in Stein. Some of our plans relate to the self-healing SIG effort: finish the integration with Monasca, allow configuring Vitrage via Heat templates for auto-healing scenarios, and in general integrate with more datasources - both OpenStack and external. * Extend the Vitrage support for Kubernetes. In addition to performing root cause analysis over Kubernetes nodes, we would like to consider also Helm charts, Kubernetes deployments, and optionally pods. * Improve the Vitrage UI, hopefully using a new React-based plugin. * Extend the Vitrage community. I'll be happy to see more contributors joining our effort. I look forward to working with you all in the coming cycle. Thank you, Ifat.

1 0

[ptl][puppet][election] PTL Candidacy
by Shengping Zhong 12 Mar '19

12 Mar '19

Hello OpenStackers, I'm submitting myself as PTL candidate for the Puppet OpenStack project during the Train cycle[1]. I've been active in the OpenStack community since 2016 and as core reviewer from Ocata cycle. My stats for the last 90 days can be viewed here[2]. My goals for the Train cycle in the following areas: * Deprecate many parameters and remove a lot of deprecate parameters. * Improving documentation around established patterns and best practices. * Add python3 packages support. * Improve testing of Puppet 6. * Improve the puppet-senlin module. * Fix some bugs. I'm happy to welcome new contributors to the project. Thanks for taking the time to read through this roadmap and to consider my candidacy. [1]https://review.openstack.org/#/c/642655/ [2]https://stackalytics.com/report/contribution/puppet%20openstack-group/90 Best regards Shengping Zhong (zhongshengping)

1 0

[ptl][octavia][election] PTL Candidacy
by Adam Harwell 12 Mar '19

12 Mar '19

Hey ya'll! As it seems that Michael is finally stepping down from his role as PTL this cycle (which I find deeply depressing, as I believe he is the best PTL we could ask for), I suppose someone has to try to fill the gaping void left by his departure. I humbly submit that I will do my best, if you'll let me try. As a contributor to Octavia since its inception (which seems so long ago now), I have had the privilege of working closely with most of you over the years, and I have been continuously proud of the things we have accomplished together. Stein will be yet another great release, with an impressive set of new features and fixes that should make Octavia easier to use for operators and users alike. Provider and flavor support especially is a big win, as it will finally allow us to drop support for neutron-lbaas, and pave the way for more broad adoption in the near future. I hope that we can continue with the momentum we've maintained in the past few years, and do great things together in Train. If you choose me, I *will* be relying heavily on each and every one of you for support, as Michael's shoes seem impossible to fill alone, especially as a newbie to PTL life. I hope we can count on each other as we continue this great adventure, and I hope to see many of you soon in Denver! Thanks, --Adam Harwell

1 0

[monasca][elections] Candidacy for Monasca PTL
by Witek Bedyk 12 Mar '19

12 Mar '19

Hello, I would like to announce my candidacy to continue as the PTL of Monasca for the Train release. In the next release I would like to focus on the following goals: * strengthen the community and improve active participation and contribution * consolidate the project by concentrating on the core functionality (metrics, logs, events), reducing legacy components and upgrading middleware * continue working on and promoting containerized deployment and Prometheus integration * continue to improve the documentation * collaborate with other OpenStack projects, e.g. by contributing to self-healing and auto-scaling SIGs Apart from that I'll do my best to promote Monasca and coordinate community work. Thank you for considering my candidacy and I'm looking forward to another very productive cycle. Best greetings Witek

1 0

[ptl][tacker][election] PTL Candidacy
by Dharmendra Kushwaha 12 Mar '19

12 Mar '19

Hi Everyone, I would like to announce my candidacy again for Tacker PTL role for Train cycle. I am Dharmendra Kushwaha known as dkushwaha on IRC, active member of Tacker community since Mitaka release. I run as Tacker PTL in Stein cycle. I would like to thanks all who supported Tacker with their contributions in Stein cycle. It is a great experience for me to working in Tacker project with very supportive contributors team. In Stein cycle we planned limited features level activities and more towards project stability and max test & code coverage things. We were able to deliver some rich features like VDU auto-healing and VNF resource reservation, and multiple other features & improvements with the help of great team support. Some of our planned activities are still in progress, and hope to complete them soon. My plan for Train cycle will be more towards: * Tacker CI/CD Improvement: - In stein cycle we added large number of test unit cases, but still we have to work in this area to get max coverage. - Focus to introduce more functional and scenario tests. * Tacker stability & production ready: - Focus to have more error-handling and significant logging. * More towards NFV-MANO rich features: - Make Tacker more ESTI compatible. - CSAR support. * More works in SFC area. * Enhancement on container based VNFs. * More physical gathering of Tacker team in OpenStack conferences. You can find my complete contributions here: http://stackalytics.com/?release=all&project_type=all&metric=commits&user_i… Thanks for reading and consideration my candidacy. Thanks & Regards Dharmendra Kushwaha IRC: dkushwaha

1 0

[ptl][magnum][election] PTL Candidacy
by feilong 12 Mar '19

12 Mar '19

Greetings, I would like announce my candidacy to serve as the Magnum project team leader for the Train cycle, if you will have me. I've been working on and contributing to Magnum since Queens release as a core developer. And I have done a lot work for Magnum to help it getting production ready, e.g. the Calico network driver, nodes anti affinity, k8s health status check, Keystone auth, coreDNS autoscale, get Magnum certified by CNCF and etc. That said, I really understand the ups and downs which Magnum went through and I know the blueprints, direction and pains of this project, for interests from both private cloud and public cloud sides. For Train release (including the rest of Stein cycle), things I'd like to do: 1. Rolling upgrade Rolling upgrade is one of the most important features user want to see for a managed Kubernetes service. And in Magnum, we're thinking more deeper to provide a better user experience. For the rolling upgrade, we will support upgrade the base operating system, Kubernetes version and even add-ons running on top of Kubernetes. 2. Auto scaling/healing Another most wanted feature for Kubernetes cluster. With this feature, a user will be able to get an auto scaled cluster which can fix itself when there is any node failure. 3. Node groups Node groups provide users with the ability to specify groups of nodes with different properties for different purposes. Within the scope of a group users are able to define labels, used image, flavor, etc depending on the purpose. 4. Fedora CoreOS The most matured driver for Kubernetes in Magnum is Fedora Atomic, however, the Fedora community is moving to Fedora CoreOS, so we should start to think about the migration. 5. Containerize Kubernetes master This could be one of the most interesting features for Magnum and it's definitely hard work. Running Kubernetes master nodes in a seed/root Kubernetes could bring us a lot of benefits. 6. Helm for add-ons We have enabled Helm in Stein and this gives us a good opportunity to re-think our add-ons management strategy. Using Helm for our add-ons could make our vendors' life much easier. It has been a fantastic experience working with this amazing team and I know without the dedication and hard work of everyone who has contributed to Magnum we can't get those good work done. So the PTL of this cool team is most like a facilitator, coordinator, and mentor. I would be pleased to serve as PTL for Magnum for the Train cycle and I'd appreciate your vote. Thanks for your consideration! -- Cheers & Best regards, Feilong Wang (王飞龙) ------------------------------------------------------ Senior Cloud Software Engineer Tel: +64-48032246 Email: flwang(a)catalyst.net.nz Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington ------------------------------------------------------

1 0

[edge][nova][neutron][ironic][cinder][tripleo] Tagging edge related work items
by Ildiko Vancsa 11 Mar '19

11 Mar '19

Hi, As edge computing related topics and work items are hot topic on both architecture level as well as on the design and implementation side it would be great to be able to see the big picture better to be able to follow activities and connect the dots. I’m reaching out to you to get some feedback and discussions around ideas to get closer to this desire. It came up on the Edge WG meetings earlier that it would be desirable to track ongoing feature development and bug fixing activities that are relevant to edge. In order to create the least overhead and try to keep things simple and somewhat automated we had the idea of tagging relevant work items in StoryBoard and Launchpad and we can also do the same with spec reviews in case we feel that the tracking tools don’t give full coverage on ongoing activities. We could use a simple tag like ‘edge’ or come up with more meaningful ones if we feel the need. The goal for this first step is to be able to filter in the already existing tools to find work items easier. What do you think about the above idea as a starting point? Do you think it is feasible or do you have any suggestions to either tweak it or coming up something else that might work better? Thanks and Best Regards, Ildikó

3 3

[ptl][adjutant][election] PTL Candidacy
by Adrian Turjak 11 Mar '19

11 Mar '19

Hello OpenStackers, I'm submitting myself as the PTL for Adjutant during the Train cycle. As the main developer and project lead until now, I'm still the best suited to continue leading the project. My focus for Train will be onboarding of new devs, and having them help me with the refactor work that is still in progress. As such the planned work is still: - bringing the codebase to a much nicer state while decoupling certain elements of our internals, and adding support for async task processing. - rework the config system - introduce partial policy support rather than relying on hardcoded decorators. - rework notifications to be pluggable and how/when they are sent - rework the identity manager as a pluggable construct. - finish the long planned support for sub-project management - add project (and resource) termination logic which uses the currently planned community goal for Stein It should actually be a productive cycle, and we will in all likelihood be dropping python2 support by the end of it. Cheers, Adrian Turjak

1 0

[ptl][nova][election] PTL Candidacy
by melanie witt 11 Mar '19

11 Mar '19

Dear Stackers, It has been my privilege to serve as PTL of the Nova project over the Rocky and Stein cycles, and I would be happy to serve another cycle, if you'll have me. I remain most motivated by serving operators and users in our community. I spend as much time as I can communicating with operators at the Summit Forum, the PTG, and the #openstack-nova channel to answer questions, help with problems, give guidance, obtain feedback, and make changes and improvements based on their feedback. I am proud to say that we receive operator code contributions regularly in Nova, and I want to do everything we can to keep it that way or even increase it. Similarly, it's always great when operators participate in our Summit Forum and/or PTG sessions. We always have participation and I appreciate that. To operators: if there is anything I can do to help you participate, please let me know. Stein was a busy cycle, with one of the primary efforts being the placement service extraction. This was an enormous change with significant impact on operators, and I worked hard to ensure we had a plan that would consider the consumers of our deliverables. I consulted with team members with expertise in upgrades and deployment tooling and strove to find consensus among members of different groups with different priorities. We made a lot of progress on the placement extraction plan, but because upgrade support and testing were not able to be implemented in deployment tools in time, we did not delete the placement code from Nova in Stein. The placement code is left as a bridge for operators in Stein, to be able to run with integrated placement until we have upgrade support and testing and operators feel ready to move to extracted placement. So, next cycle, we have a lot of important cross-project work to do with deployment tools teams to coordinate upgrades support and testing, and removal of the placement code from Nova. This of the highest priority. In Stein, I worked on two features focused on usability and operational robustness: configurable maximum number of disk devices to attach to a single instance and counting quota usage from placement (down/poor performing cell resiliency). We landed only the data migration piece of the counting quota usage series, but that positions us well to be able to migrate a lot of data in Stein and start counting quota usage from placement in Train. Next cycle, I want to focus on coordinating what deployment tools need to support upgrading to extracted placement and deletion of the placement code in Nova, project management duties, and bugs. It is essential that we get the upgrade/extracted placement work squared away in Train, as early as possible. Finally, cross-project efforts are important to me and I participate in discussions whenever I can. I actively participated in most of the unified limits/oslo.limit sessions at summit and PTG, to lend my experience working with quotas in Nova to help those working on the design and implementation. And recently, I had a productive discussion with Lance Bragstad about Keystone authorization scopes, which resulted in him drafting this great document for all of us: https://review.openstack.org/638563. I want to help drive adoption of auth scopes in Nova, to help Nova become more self-service and enable operators to let non-admin users have access to whatever APIs they choose. Thanks for reading and thank you for your consideration. Best, -melanie

1 0

[ptl][neutron][election] PTL Candidacy
by Miguel Lavalle 11 Mar '19

11 Mar '19

Hello OpenStackers, I write this to submit my candidacy for Neutron PTL during the Train cycle. I have had a blast being the project's PTL for the past three cycles. After everything is said and done, the most rewarding part of this job is to get to work with an amazing group of top notch software engineers from around the World. I will be grateful forever for everything that you all have taught me. So I humbly ask for another chance to be trained during Train. We had a successful Stein cycle, delivering on most of the goals we set for ourselves in Denver: * Delivered most of the implementation of bandwidth based scheduling, that enables Neutron and Nova to guarantee network bandwidth to instances based on QoS policies. * To better serve edge computing use cases, we partnered with the StarlingX team to implement management of network segments ranges dynamically through a new API extension. * Extended Neutron QoS to support L3 router gateway IPs. * Improved the performance of port creation in bulk to better support containers use cases. * Improved the security groups implementation by optimizing the performance of rules creation and making security groups shareable with the RBAC mechanism. * We created the os-ken project, OpenStack community fork of the Ryu library, which will not be supported by its original implementor anymore. os-ken is now maintained by the Neutron project team. * We continued our efforts of de-coupling common functionality from the Neutron repository and moving it to neutron-lib. * We worked hard on past and present community goals, so at the end of Stein Neutron will be completely caught up. * We implemented a successful mentoring program for prospective core reviewers. This enabled us to add three new members to the Neutron team: Nate Johnston, Hongbin Lu and Liu Yulong. We also added Bernard Cafarelli, Ryan Tidwell and Manuel Buil as stable branches, BGP Dynamic Routing and networking-sfc core reviewers, respectively. Moving forward, these are some of the goals that I propose for the team during the Train cycle: * Improve the usability of routed networks by allowing more that one segment per network per compute host. This will enable the scaling up of deployments without being constrained by subnet IP address ranges. * Add the capabillity to tag ports during bulk creation, to better support containers use cases. * Actively continue our collaboration with the StarlingX team to identify and implement better support for edge computing use cases. * Continue the implementation of smart NICs support. * During Stein, we formed a performance sub-team with the aim of improving Neutron's scalability. We will bring this effort to fruition by identifying and implementing areas of improvement based on the characterization work we are doing with osprofiler and the EnOS (Experimental eNvironment for OpenStack) team. * We will continue our efforts of de-coupling common functionality from the Neutron repository and moving it to neutron-lib. * I see myself, with the support of my current employer, actively involved in the project and the community for many cycles in the future. I think, though, that we are getting to a point where it is healthy to pass the baton to a new leader. To that end, I will actively encourage team members to step up to the plate in the next cycle. I will support and help propective candidates every step of the way. Thank you for your consideration and for taking the time to read this Miguel Lavalle (mlavalle)

1 0

[all][ptl]tc] Only 24 hours remaining for PTL nominations
by Jeremy Stanley 11 Mar '19

11 Mar '19

A quick reminder that we are in the last hours for PTL candidate nominations. If you want to stand for PTL, don't delay, follow the instructions at [1] to make sure the community knows your intentions. Make sure your nomination has been submitted to the openstack/election repository and approved by election officials. The following projects are still lacking any PTL candidate at this time: Adjutant Congress Glance Heat I18n Magnum Monasca Neutron Octavia OpenStack Helm PowerVMStackers Puppet OpenStack Tacker Telemetry Tripleo Vitrage Zaqar This means that with approximately 1 day left, these 17 projects may be deemed leaderless. In this case the TC will oversee PTL selection as described by [2]. Thank you, [1] https://governance.openstack.org/election/#how-to-submit-a-candidacy [2] https://governance.openstack.org/resolutions/20141128-elections-process-for… -- Jeremy Stanley

1 0

[ptl][ironic][election] PTL Candidacy
by Julia Kreger 11 Mar '19

11 Mar '19

Greetings fellow carbon based lifeforms and sentient software programs, I would like announce my candidacy to serve as the Ironic project team leader for the Train cycle, if you will have me. Passion is a funny thing. It drives us and motivates us, but it does not tell us when we are done. And I can say for certain that I am not done. Last cycle we turned the dial to eleven and this cycle we've reached twelve. I suspect we need to re-calibrate the dial and begin a new standard for audio volume measurement. We achieved more than I could have imagined for this past cycle, but not quite what we planned. Our wants, desires, purpose, and meaning are fluid. It is clear to me we evolved because the needs of those we support have changed while keeping a single central theme. To make it easier to deploy and manage bare metal. To continue on this journey, I think we must embrace and extend our operator community. Just as with our use cases and hardware support. We must no longer think of ourselves as only a service with-in the confines of OpenStack. We must view beyond our OpenStack roots while continuing to strengthen them. We can only do this by growing our community. Together, I am sure we can further make bare metal rock. And perhaps, somewhere along the way, we may take over the world. Julia Kreger (TheJulia)

1 0

[ptl][tacker][election] Only one more day to submit your candidacy for Tacker PTL
by Trinh Nguyen 11 Mar '19

11 Mar '19

Hi team, Just so you know that we have only 1 more day left [1] to submit your candidacy for Tacker PTL. Please do it asap. Bests, [1] https://governance.openstack.org/election/ -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[edge][all] Edge hacking days
by Ildiko Vancsa 11 Mar '19

11 Mar '19

Hi, A few of us in the Edge WG are working on to organize hacking days[1] to ensure we can have some dedicated time to progress with work items as well as speed up the learning phase in areas like identity or image management or bootstrap testing activities. Our thinking is to organize these as virtual events through Google Hangouts or any other tool we prefer to use to keep in contact. We can also leverage conferences to try and organize in person occasions even if not for a full day. Would you be interested in participating? If yes what is the topic/task you would like to work on? Thanks and Best Regards, Ildikó [1] http://lists.openstack.org/pipermail/edge-computing/2019-March/000555.html

1 1

[ptl][cinder][election] PTL Candidacy ...
by Jay Bryant 11 Mar '19

11 Mar '19

All, This letter is to indicate my interest in continuing to serve as the Cinder PTL for the Train release. This would be my fourth release as PTL and am happy to continue leading the Cinder project. Over the last three releases, for which I have been PTL, I have seen Cinder transition from focussing on merging new functionality to focussing on fixing bugs and improving Cinder's stability. This is a natural progression for a project of this type and, I feel, requires the team to take a new approach to how we go forward. During the Train release I think that the team should continue to look at the bugs filed against Cinder and work to address them. We started reducing the number of bugs during Stein and I hope that we can continue that momentum in Train. I also feel that we need to be better about monitoring 3rd Party CI runs and ensure that they are testing what they should be testing. With the move to Python3 ensuring it is being tested and that each driver works with Python3 is going to be essential. Other goals I have during Train include: * Continuing to address how cinderlib fits with Cinder * Continuing to reach out to our users seeking their input for improvement * Continued improvement of core reviewer participation * Increasing the breadth of testing against Cinder I look forward to the continued opportunity to lead the Cinder project. Sincerely, Jay Bryant (jungleboyj)

1 0

[all][ptl][tc] Missing PTL nominations for 31 more teams
by Jeremy Stanley 11 Mar '19

11 Mar '19

A quick reminder that we're still missing "Train" cycle PTL candidate nominations for nearly half our official teams: Adjutant Blazar Chef OpenStack Cinder Congress Designate Glance Heat Horizon I18n Ironic Magnum Manila Mistral Monasca Neutron Octavia OpenStack Helm PowerVMStackers Puppet OpenStack Qinling Rally Storlets Tacker Telemetry Tricircle Tripleo Trove Vitrage Zaqar Zun This means that with approximately 2 days left, 31 projects will be deemed leaderless. In this case the TC will oversee PTL selection as described by [1]. (Any open reviews[2] have not been factored into these stats.) If you want to stand for PTL, don't delay, follow the instructions at [3] to make sure the community knows your intentions. Make sure your nomination has been submitted to the openstack/election repository and approved by election officials. Thank you, [1] https://governance.openstack.org/resolutions/20141128-elections-process-for… [2] https://review.openstack.org/#/q/is:open+project:openstack/election [3] https://governance.openstack.org/election/#how-to-submit-a-candidacy -- Jeremy Stanley

3 3

[tripleo] Nova HWMachineType settings
by Wesley Hayutin 11 Mar '19

11 Mar '19

Greetings, As we started to bootstrap f28 standalone jobs we noticed basic tempest tests were failing because the libvirt on f28 did not support the default "x86_64=pc-i440fx-rhel7.6.0" [5] Kashyap recommend switch to q35 [1]. So we can change to q35 maybe globally in puppet [2] if Juan, Alex and Emilien approve. Alternatively we can isolate the deployment in question w/ [3],[4] I should restart this thread in openstack-dev[tripleo] for greater transparency. Thanks Any comments on how to proceed? We need to enable f28 jobs in the next few days, so [2] may need to be the short term answer until we get feedback. [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8-be… [2] https://review.openstack.org/#/c/642443/ [3] https://review.openstack.org/#/c/642517/ switch to "pc" [4] https://review.openstack.org/#/c/642547 switch to "q35" [5] http://logs.rdoproject.org/openstack-periodic/git.openstack.org/openstack-i…

1 0

[tc][all][sdk] Devs and feedback needed for 'Project Resource Cleanup' goal for Train cycle
by Adrian Turjak 11 Mar '19

11 Mar '19

Hello OpenStackers! As has been mentioned a few times on the mailing list, one of the current community goal proposals is a new library/tool for cleaning up all the resources for a given project in an OpenStack cloud. For a long time we've lacked something like this, and it has made cleaning up a project and deleting it a pain, specifically because of the various dependencies around resources. The goal is now up for review: https://review.openstack.org/#/c/639010 The discussion right now is around the version originally proposed and discussed at the last Summit, a plugin based solution with a central library. We are also looking at an alternative which would be a single library like the SDK, or potentially even including the deletion login in the SDK itself, and the CLI part in the OpenStackClient. In all likelihood the single library approach will end up chosen, and I'll have a new written version of the goal up soon for that. If you have feedback against that you should voice it now! Are there any arguments for or against a plugin based solution we haven't heard yet? Additionally we would like feedback (specifically from the SDK team) if they think we should keep this as a standalone library that uses the SDK, or make it part of the SDK. We also need additional developers willing to contribute their time to this goal. Ideally we want every service to have some say in the code to clean up their resources, so I would highly suggest each new PTL works with their team to see who wants to help us make sure they are represented in this goal. Let's actually make this goal a reality! Put your hand up for wanting to contribute review time, and code! Cheers, Adrian

3 2

[tc] weekly update
by Mohammed Naser 11 Mar '19

11 Mar '19

Hi everyone: Just wanted to keep everyone up to date on what's going on in the TC over the past week briefly, this is meant to be a quick digested update that can (and should!) spark up some conversation, so please feel free to ask questions or bring in ideas # Python 3 The TC met and discussed last week about finalizing everything regarding Python 3. This happened over an ad-hoc meeting which you can follow the minutes here alongside the action items that came out of it - http://eavesdrop.openstack.org/meetings/tc_python3/2019/tc_python3.2019-03-… # Cycle goals There has also been work done from Lance and Jean-Philippe regarding the cycle goals, input from projects would be really useful, please have a look at them here: - https://review.openstack.org/#/c/639376/ Add Move legacy client CLIs to OSC goal to Train - https://review.openstack.org/#/c/639010/ Add Project Deletion goal for Train # Business value of help most needed Lance has put in a lot of work and effort in terms of moving our help most needed document to something that explains business value, reviews are up: - https://review.openstack.org/#/c/641790/ Elaborate on the business value of Designate - https://review.openstack.org/#/c/641773/ Elaborate on the business value of goal champions - https://review.openstack.org/#/c/641750/ Elaborate on the business value of documentation owners - https://review.openstack.org/#/c/641890/ Elaborate on the business value of infra admins - https://review.openstack.org/#/c/641784/ Elaborate on the business value of Glance # Goal closure updates Matt has pushed up a change discussing what to be done "at the end of a goal" which is currently up for discussion: - https://review.openstack.org/#/c/641507/ Document goal closure # Other Thanks to Doug once again for serving as chair for the past few cycles. The PTG is coming up and we're excited to see all the community again to build Train, without the train background noise :) Thanks, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

1 0

[tc] selecting a vice chair
by Mohammed Naser 11 Mar '19

11 Mar '19

Hi everyone: Thanks for having me serve as chair for the upcoming session. As part of my duties getting started is appointing a vice chair[1]. I'd like to invite those who would like to run for vice chair to personally contact me, as I think it's a great way to ease into the TC workflow and learning more about the inner workings of how we (try?!) to keep things moving. I'll be assigning someone by Tuesday, so I just wanted to extend this for those who wanted to run to contact me. :) Thanks, Mohammed [1]: https://governance.openstack.org/tc/reference/charter.html#tc-chair -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

1 1

[horizon][plugins][vitrage][heat][ironic][manila] Integration tests on gates
by Ivan Kolodyazhny 11 Mar '19

11 Mar '19

Hi team, A few weeks ago we enabled horizon-integration-tests job[1]. It's a set of selenium-based test cases to verify that Horizon works as expected from the user's perspective. Like any new job, it's added in a non-voting mode for now. During the PTG, I'd got several conversations with project teams that it would be good to have such tests in each plugin to verify that plugin works correctly with a current Horizon version. We've got about 30 plugins in the Plugin Registry [2]. Honestly, without any kind of testing in most of the plugins, we can't be sure that they work well with a current version of Horizon. That's why we decided to implement some kind of smoke tests for plugins based on Horizon integration tests framework. These tests should verify that a plugin is installed and pages could be opened in a browser. We will run these tests on the experimental queue and/or on some schedule on Horizon gates to verify that plugins are maintained and working properly. My idea is to have such a list of 'tested' plugins, so we can add 'Maintained' label to the Plugin Registry. Once these jobs become voting, we can add a label 'Verified'. I think such a schedule looks reasonable: * Stein-Train release cycles - add non-voting jobs for each maintained plugin and introduce "Maintained" label * Train-U release cycles - makes stable jobs voting and introduce "Verified" label in the Horizon Plugin registry I do understand that some teams don't have enough resources to maintain integration tests, so I'm stepping as a volunteer to introduce such tests and jobs for the project. I already published patches for Vitrage and Heat [3] plugins and will do the same for Ironic and Manila dashboards in a short time. Any help or feedback is welcome:). [1] https://review.openstack.org/#/c/580469/ [2] https://docs.openstack.org/horizon/latest/install/plugin-registry.html [3] https://review.openstack.org/#/q/topic:horizon-integration-tests+(status:op… Regards, Ivan Kolodyazhny, http://blog.e0ne.info/

3 3

Firmware Update (cleaning step) issues
by Martin Sysadmin 11 Mar '19

11 Mar '19

Hi all I wondered if anybody had managed to update ILO firmware via openstack cleaning step? Details: openstack triple-o / RDO containerised deployment (ironic_conductor etc is a Docker container on the under cloud) I have constructed a JSON file with the contents as follows: [ { "interface": "management", "step": "update_firmware", "args": { "firmware_update_mode": "ilo", "firmware_images":[ { "url": "https://.../..../CP0xyz.scexe", "checksum": "<checksum_value>", "component": "ilo" } ] } } ] which I then initiate a clean step test using following: openstack baremetal node clean --clean-steps fw_update_test.json mytestnode.test.local and this fails with the error "Clean step update_firmware *failed* on node <<node_uid>> with the error: Unable to update firmware" when looking in /var/log/containers/ironic/ironic-conductor.log I have tested this myself by importing proliantutils into my own test Python script, it doesn't matter what URL I provide it fails with the error above. Has anyone managed to get this step working at all? I have also tried with unpacked image (.bin file) and the same error. Would appreciate any tips Thanks

2 2

[ptl][election][horizon] PTL candidacy
by Ivan Kolodyazhny 11 Mar '19

11 Mar '19

Hi, I would like to announce my candidacy for PTL of Horizon for Train release. I served this role during the last two releases and I still feel strong enough to do this role during the next six months. We did a good job as a team during the Stein release cycle: enabled integration tests both for Horizon and several plugins created a good list of priorities and TODOs to fix our huge feature gaps between UI and command-line clients and started work on them, so you can find a few more useful features in our release notes. During the Train cycle, I’m going to continue these efforts: * Add integration tests for all maintained plugins so we can be sure that we’ve got a verified list of working Horizon plugins. * Involve project teams in Horizon: even such contributions like feature requests are extremely important to understand what should we do to make cloud users and operators happier * We missed few community goals in the past and I’ll do my best to fix it in Train release. * Last, but not least, I’ll be happy to help new contributors to be a part of Horizon team. I hope you’ll give me a chance to wear a PTL hat for Train and help me with all these efforts. Thank you, Ivan Kolodyazhny (e0ne)

1 0

[ptl][manila][election] Tom Barron manila PTL candidacy
by Tom Barron 11 Mar '19

11 Mar '19

All, I served as Manila PTL for Rocky and Stein and am willing and able to take on that role in Train if you choose me. I continue to be less interested in adding new features to Manila itself than in improving its durability, ease of use, and consumability. I will continue to get the message out that Manila is loosely coupled with other OpenStack components and serves up storage via the network rather than through hypervisors so that it is ideally positioned to provide shared file storage both within and outside of OpenStack proper. I will work to make sure that storage vendors understand that if they maintain drivers for their back ends in Manila then this will at the same time enable them to provide storage for OpenStack consumers and also for Container Orchestrator clouds. I will continue to champion development of "**production quality**" 100% open source storage back ends for Manila. We have done a good job fostering new contributors and helping outreachy intern applicants get started. I want us to continue to be known as a friendly project and a good place to work. In Train we need to complete work already begun to: * build a manila CSI plugin * integrate manila into the OpenStack Client and SDK * integrate manila into OpenStack ansible and extend TripleO coverage to more storage back ends. In addition, in the Train cycle I want the Manila project to take up the challenge of shared storage as a service at the Edge. We need to: * Articulate use cases for shared storage (vs block or object) at the Edge. * Drive common understanding of appropriate service architecture for Edge. * Position vendors and open source software defined back ends for Edge deployments using Manila. These are the things that will drive me if you choose me as manila PTL. Thanks for listening, -- Tom Barron (tbarron)

1 0

[designate][election][ptl] PTL Candidacy
by Graham Hayes 11 Mar '19

11 Mar '19

Hi All, I would like to announce my candidacy for PTL of Designate for the Train cycle. I have been PTL for Mitaka, Newton, Ocata, Queens, Rocky, Stein (and hopefully Train), and have been a core for longer. I have been part of teams that ran Designate in production in public clouds, and also shipped products based on it. I feel that this gives a great viewpoint for where we should go. That said, leadership turn over is healthy, and is required to ensure that a project does not get stale, and in Designate we have been very bad at ensuring there is a good turn over (Designate has had 3 PTLs in its existance, 2 of which were originally from Managed I.T. - the company that founded it). As a result, Train will be my last cycle as PTL (if you see fit to elect me). My cycle goals will be to ensure a clean handover to the next PTL - writing down roadmaps, documenting what I do as PTL, and guiding anyone who is interested in taking on the role. While DNS is not something that is traditionally on a hype curve, we have had solid growth over the years, and the software we write is deployed in some of the largest OpenStack users. It is an important part of the Datacentre as a Service space, and we should be proud of it, and help promote its use where it fits. Thank you for taking the time to read this, and thank you for your support. - Graham (mugsie)

1 0

[ptl][election][mistral] PTL candidacy
by Renat Akhmerov 10 Mar '19

10 Mar '19

Hi, After a year break I'd like to announce my PTL candidacy for Mistral in Train cycle ([1] is the official patch to openstack/election). I’d like to thank Dougal Matthews who was the PTL from Feb 2018 up to the middle of Dec 2018 and performed really well in this period. In Dec Dougal decided to step down due to the changes in his work priorities and I agreed to take over. In the last two years we've been mainly focused on improving Mistral performance and the reason for this was that some big users began to adopt it for their production needs. The amount of work done in this area was huge and the result is orders of magnitude boost for a number of use cases. Although much was done and the core of the technology is pretty mature now, there's still a lot ahead: 1. Continue to improve performance (e.g. "join" tasks) 2. Make the technology more product-like. That is, eliminating obvious gaps in the documentation (inconsistent structure, lack of tutorials, etc.), installation and configuration tools, tools for developing custom actions and functions easier and plugging them in easier. The ultimate goal here is to make sure that a new user can start using the technology within minutes, and the experience should be as positive as possible. Another thing that I'd like to do is to attract more talented and qualified contributors, i.e. to make the project community stronger. So if one has interest in working on Mistral we're always open and ready to help witn getting up to speed. Most likely, not all of the things mentioned above will be done in Train but I want to make sure we finally started addressing #2 in a more serious way than before. The best way to get in touch with us is IRC channel #openstack-mistral or the openstack-discuss mailing list (with [mistral] tag in email subject). [1] https://review.openstack.org/#/c/642336 Thanks Renat Akhmerov @Nokia

1 0

[sdk] Request to release newer version of openstacksdk for Stein Cycle
by Patil, Tushar 10 Mar '19

10 Mar '19

Hi SDK team, I have requested a release of openstacksdk which includes changes to the instance-ha service to get the recovery workflow details of the notification. Kindly consider our request on behalf of Masakari team to release a newer version of openstacksdk so that we can use this newer version in masakari-dashboard [1] to render the recovery workflow details on the notification screen. Thank you in advance for your cooperation. [1] : https://review.openstack.org/#/c/640755/ Regards, Tushar Patil Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.

4 5

[neutron] Cancelling the Neutron Performance sub-team meeting
by Miguel Lavalle 10 Mar '19

10 Mar '19

Ho Team, I will be travelling March 11th on a business trip. As a consequence, we will cancel the performance sub-team meeting. We will resume normally on the 25th. Best regards Miguel

1 0

[cloudkitty] PTL candidacy
by Luka Peschke 10 Mar '19

10 Mar '19

Hello everybody, I would like to submit my candidacy as CloudKitty's PTL for the Train cycle. I've been contributing to the project since the Newton release and I've been the PTL for the Stein cycle. As a PTL, I'd like to keep working on the points we addressed during the last cycle: * Help CloudKitty's community to grow. Some work has been done during the stein cycle (IRC meetings have been reintroduced, the developer documentation has been improved...), but we need to keep putting effort into this. * Improve the documentation. Here again, this has been worked on in Stein (there have been a lot of documentation patches), but we are far from done. * Add missing features: I'd like to mentor developers willing to add endpoints to the v2 API, which has been added during the stein cycle. We have also been talking a lot about a new rating engine recently. It would be great to have a spec draft for this, on which we could work together. Thank you for your attention, Luka Peschke (peschk_l) Envoyé avec AquaMail pour Android https://www.mobisystems.com/aqua-mail

1 0

[searchlight] Team meeting today at 13:30 UTC
by Trinh Nguyen 10 Mar '19

10 Mar '19

Hi team, We will have a team meeting today at 13:30 UTC on #openstack-searchlight as usual. Please check out meeting agenda at [1]. Bests, [1] https://etherpad.openstack.org/p/search-team-meeting-agenda -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[dev][qa] New time options for QA Office Hour
by Ghanshyam Mann 10 Mar '19

10 Mar '19

Hello Everyone, As you all, I have been moved to CST TZ, which need to select the new time for QA office hour. Till now, we have scheduled two office hours ( Thursday every week at 09:00 UTC and 17:00 UTC) and 17 UTC was not so active. Let's covert two office hours into one and select the new time for the same. I have created the doodle vote for that, please cast your vote as per your availability and schedule. Or let me know if none of the options are good so that I can propose the new time. - https://doodle.com/poll/pugm7nx7eskwfczx -gmann

1 1

[placement] update 19-09
by Chris Dent 10 Mar '19

10 Mar '19

HTML: https://anticdent.org/placement-update-19-09.html Here's another placement update. It was feature freeze this week so people are probably a bit worn, I'll try to keep this light and quick. # Most Important We need to decide if we want to do what amounts to a feature freeze exception for Tetsuro's negative member-of handling linked below and work out how/when to fit Mel's allocation ratio work on osc-placement (also below) into the world so people can use it. If people have placement related forum sessions they would like to see happen the deadline is either today (March 8th) or Monday, depending on which and how you read various pieces of info. Matt has already set up an extraction-related session. It's also important to be thinking about how placement would like to engage (as a group) with the PTG. If you want to run for PTL (of placement or anything else) the deadline is 23:45 UTC, 12 March. # What's Changed * The refactoring of the objects/resource_provider.py file into smaller, more single-purpose files, continues to merge. In case anyone is feeling like this is a lot of churn for little purpose, it does have purpose: This is making the code more accessible to people who aren't familiar with it. It is also providing a good review (a variety of warts and bugs and have been found and fixed) of stale code. * pep8's whitespace handling has been turned back on in placement. We inherited the exceptions to the rules from nova, where fixing for those rules would have been messy. In placement it wasn't that much of a big deal. * A conf setting `[placement_database]/sync_on_startup` has been added. Defaults to `False`. If `True`, the web service process will attempt the equivalent of `placement-manage db sync` at startup. * Improved debug logging when requesting allocation candidates, so that operators can more accurately determine what requirement led to reduced or no available hosts. * [1.5.0 of osc-placement](https://pypi.org/p/osc-placement) was released. It now goes up to microversion 1.18 (filter resource providers by required traits). (Note to everyone: We should make the info that shows up on PyPI more useful, by changing the README). * VGPU reshaping for libvirt merged! # Specs/Blueprints/Features ## Near to Done * [Filter Allocation Candidates by Provider Tree](http://specs.openstack.org/openstack/nova-specs/specs/stein/approved/… has been mostly completed by Tetsuro, but there's a [pending update to the spec](https://review.openstack.org/639033). * [Support filtering by forbidden aggregate membership](http://specs.openstack.org/openstack/nova-specs/specs/stein/app… also mostly [completed by Tetsuro](https://review.openstack.org/#/q/topic:bp/negative-aggregate-membe…. ## Not yet Done These will get punted to Train. * [Support any traits in allocation_candidates query](http://specs.openstack.org/openstack/nova-specs/specs/stein/approved… * [Support mixing required traits with any traits](http://specs.openstack.org/openstack/nova-specs/specs/stein/approve… ## Not yet Approved * [Resource provider - request group mapping in allocation candidate](https://review.openstack.org/#/c/597601/) has had a recent resurgence in attention. # Bugs There is a storyboard [project group](https://storyboard.openstack.org/#!/project_group/placement) for placement projects. Through to the end of Stein we'll be paying attention to both it and Launchpad. The sole story in storyboard right now is updating docs to indicate we are using storyboard. So meta! In launchpad: * Placement related [bugs not yet in progress](https://goo.gl/TgiPXb):13. -2. * [In progress placement bugs](https://goo.gl/vzGGDQ) 9. -8. That large drop on in progress is because I went through and caught up those bugs which had fixes committed but had not been automatically updated. # osc-placement osc-placement is currently behind by 13 microversions. Pending changes: * [support for 1.19](https://review.openstack.org/#/c/641094/) * [support for 1.21](https://review.openstack.org/#/c/641123/) * [aggregate allocation ratio tool](https://review.openstack.org/#/c/640898/) # Main Themes ## Nested * VGPU reshaping for libvirt merged! * The bandwidth-resource-provider topic has merged a vast amount of code but there is [some left](https://review.openstack.org/#/q/topic:bp/bandwidth-resource-provider). Some of it may still merge in Stein, but the rest will be for Train. The microversion ([2.72](https://docs.openstack.org/nova/latest/reference/api-microversion-his… provides the API-level bits to allow booting a host with a minimum bandwidth requirement. At least some of the [remaining changes](https://review.openstack.org/#/c/637953) will be backported. There were no nibbles on last week's plea, so I'll say again: If anyone reading this is in a position to provide third party CI with fancy hardware for NUMA, NFV, FPGA, and GPU related integration testing with nova, there's a significant need for that. ## Refactoring The work that removed oslo.versionedobjects then moved on to removing the List classes (e.g. AllocationList) in favor of using native Python lists and breaking up the `resource_provider.py` file into smaller files. The first portion of that (`scrub-Lists`) merged. The next stage is on [cd/de-list-phase2](https://review.openstack.org/#/q/topic:cd/de-list-phase2). This will continue until each type has its own file. # Other Placement * <https://review.openstack.org/#/c/639628/> Docs: extract testing info to own sub-page * <https://review.openstack.org/#/q/topic:cd/gabbi-tempest-job> Gabbi-based integration tests of placement. These recently found a bug that none of the functional, grenade, nor tempest tests did. * <https://review.openstack.org/#/c/630216/> Add a vision-reflection (of the Technical Vision doc). * <https://review.openstack.org/#/q/topic:bp/negative-aggregate-membership> Negative member of aggregate filtering resource providers and allocation candidates. * <https://review.openstack.org/#/c/641422/> Docs: Group API versions by release * <https://review.openstack.org/#/c/640555/> Add explicit short-circuit in get_all_by_consumer_id # Other Service Users (If you stick "placement" somewhere in your commit message I'll probably eventually find your in-progress placement-related changes.) ## Nova * <https://review.openstack.org/#/q/topic:bp/count-quota-usage-from-placement> Using placement (from nova) for counting (some of) quota. Some of this, mostly related to database migrations, managed to make it in before feature freeze, but not the part that actually uses placement to do some counting, that is still pending. * <https://review.openstack.org/621494> Add descriptions of numbered resource classes and traits ## Not Nova * <https://review.openstack.org/#/q/topic:tripleo-nova-placement-removal> * <https://review.openstack.org/#/q/topic:tripleo-placement-extraction> * <https://review.openstack.org/#/q/topic:minimum-bandwidth-allocation-placeme…> Neutron side of minimum bandwidth. * <https://review.openstack.org/#/q/bp/no-affinity-instance-reservation> Blazar reservation handling, including some manipulation of inventory in placement. * <https://review.openstack.org/633204> Blazar: Retry on inventory update conflict * <https://review.openstack.org/#/c/626382/> Kolla: Copy placement database migration script * <https://review.openstack.org/#/c/629253/> Tempest: Minimum bandwidth allocation with placement # End Go forth and document and bug fix and raise a full and flavorful stein. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

3 3

[magnum] Change `floating_ip_enabled` behavior
by Lingxian Kong 10 Mar '19

10 Mar '19

Hi, As an openstack based public cloud, we have deployed Magnum in our production recently, but we found there is something that our customer is unhappy with. One of them is when `floating_ip_enabled` and `master_lb_enabled` are both set for the Kubernetes cluster, Magnum allocates floating IPs for master load balancer VIP, etcd service load balancer VIP, each master node and even each worker node, which costs too much for the public cloud customers. So, I've proposed a patch[1] to improve that which needs feedback from the community: 1. If `floating_ip_enabled` is set, don't allocate floating IP for etcd service and worker nodes by default. The etcd service should be dedicated to the kubernetes cluster and only accessible within the cluster for security reasons. If the user has the requirement for worker node maintenance, she can manually associate floating IP with the worker node. 2. If `floating_ip_enabled` and `master_lb_enabled` are both set, don't allocate floating IP for each master node. In the multi-master scenario, all other services talk to kubernetes control plane via the master load balancer VIP, the master node itself doesn't need to be exposed to the public internet to avoid the attack surface against the cluster. If the changes above affect you, please reply this email or ping me (lxkong) in the #openstack-containers IRC channel, or leave your comments in the patch directly. Any feedback is appreciated. [1]: https://review.openstack.org/#/c/641547 Cheers, Lingxian Kong

1 0

[sdk] Request to release newer version of openstacksdk for Stein Cycle
by Tushar Patil 09 Mar '19

09 Mar '19

Hi SDK team, I have requested a release of openstacksdk which includes changes to the instance-ha service to get the recovery workflow details of the notification. Kindly consider our request on behalf of Masakari team to release a newer version of openstacksdk so that we can use this newer version in masakari-dashboard [1] to render the recovery workflow details on the notification screen. Thank you in advance for your cooperation. [1] : https://review.openstack.org/#/c/640755/ Regards, Tushar Patil

1 0

[ptl][requirements][election] Matthew Thode PTL candidacy
by Matthew Thode 09 Mar '19

09 Mar '19

I would like to announce my candidacy for PTL of the Requirements project for the Train cycle. The following will be my goals for the cycle, in order of importance: 1. The primary goal is to keep a tight rein on global-requirements and upper-constraints updates. (Keep things working well) 2. Un-cap requirements where possible (stuff like cmd2 and grpcio). 3. Publish constraints and requirements to streamline the freeze process. This is in progress, but did not make it for Stein. https://storyboard.openstack.org/#!/story/1719006 is the story tracking the publish job. 4. Audit global-requirements and upper-constraints for redundancies. One of the rules we have for new entrants to global-requirements and/or upper-constraints is that they be non-redundant. Keeping that rule in mind, audit the list of requirements for possible redundancies and if possible, reduce the number of requirements we manage. I look forward to continue working with you in this cycle, as your PTL or not. Thanks for your time, Matthew Thode IRC: prometheanfire

1 0