January 2019 - openstack-discuss - lists.openstack.org

[neutron] Switching Ocata branch to Extended maintenance
by Bernard Cafarelli 04 Jan '19

04 Jan '19

Hello and happy new year, as discussed in our final 2018 meeting [0], we plan to switch the Ocata branch of Neutron to Extended maintenance [1]. There will be a final Ocata release for Neutron itself. Stadium projects backports only included test fixes so do not really need a final release. We will then mark the branch as ocata-em. Any comments or objections? Especially from driver projects maintainers, as these have independent releases. [0] http://eavesdrop.openstack.org/meetings/networking/2018/networking.2018-12-… [1] https://docs.openstack.org/project-team-guide/stable-branches.html#extended… -- Bernard Cafarelli

1 0

[release] Release countdown for week R-13, Jan 7-11
by Sean McGinnis 04 Jan '19

04 Jan '19

Welcome back from the holiday lull! Development Focus ----------------- Teams should be focused on completing milestone 2 activities by January 10 and checking overall progress for the development cycle. General Information ------------------- The Stein membership freeze coincides with the Stein-2 milestone on the 10th. While doing an audit of all officially governed team repos, there are quite a few that have not had an official release done yet. If your team has added any repos for deliverables you would like to have included in the Stein coordinated release, please add at least an empty template deliverable file for now so we can help track those. 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. Another reminder about the changes this cycle with library deliverables that follow the cycle-with-milestones release model. As announced, we will be automatically proposing releases for these libraries at milestone 2 if there have been any functional changes since the last release to help ensure those changes are picked up by consumers with plenty of time to identify and correct issues. More detail can be found in the original mailing list post describing the changes: http://lists.openstack.org/pipermail/openstack-dev/2018-October/135689.html Any other cycle-with-intermediary deliverables that have not requested a release by January 10 will be switched to the cycle-with-rc model as discussed previously: http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000465… Upcoming Deadlines & Dates -------------------------- Stein-2 Milestone: January 10 -- Sean McGinnis (smcginnis)

1 0

[placement] [packaging] [docs] WIP placement install docs
by Chris Dent 04 Jan '19

04 Jan '19

I've started a very wippy work in progress [1] for placement installation docs within the extracted placement repository, using the existing docs from nova as a base. I'd like to draw the attention of rdo, ubuntu, and obs packagers as the docs follow the existing pattern of documenting install on those three distros. However, since placement is not fully packaged yet, I'm making some guesses in the docs about how things will be set up and how packages will be named. So if people who are interested in such things could have a look that would be helpful. I've stubbed out, but not yet completed, a from-pypi page as well, as with placement, installation can become as simple as pip install + run a single command line with the right args, if that's what you want. I think people should be able to see that too. Thanks. [1] https://review.openstack.org/628220 -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

1 0

[tc] agenda for Technical Committee Meeting 3 Jan 2019 @ 1400 UTC
by Doug Hellmann 03 Jan '19

03 Jan '19

TC Members, Our next meeting will be this Thursday, 3 Jan at 1400 UTC in #openstack-tc. This email contains the agenda for the meeting, based on the content of the wiki [0]. If you will not be able to attend, please include your name in the "Apologies for Absence" section of the wiki page [0]. [0] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee We have several items of old business to wrap up: * technical vision for openstack We have approved the first draft of the vision [1], and have one update proposed by gmann [2]. What are the next steps for this change to the vision? Are we ready to remove this topic from the tracker now, and treat further updates as individual work items? [1] https://governance.openstack.org/tc/reference/technical-vision.html [2] https://review.openstack.org/#/c/621516/ * next step in TC vision/defining the role of the TC We also approved a document explaining the role of the TC [3]. Is there more work to do here, or are we ready to remove this from the tracker now? [3] https://governance.openstack.org/tc/reference/role-of-the-tc.html * keeping up with python 3 releases We have approved all of the patches for documenting the policy and for selecting the versions to be covered in Stein. What are the next steps for ensuring that any implementation work is handled? * Reviewing TC Office Hour Times and Locations The most recent mailing list thread [4] was resolved with no changes to the number of office hours. Does anyone want to propose different times, or are we happy with the current schedule? [4] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000542… and we also have a couple of items of new business to take up: * Train cycle goals selection update Checking with lbragstad and evrardjp for any updates to share with us this month. * health check status for stein How is it going contacting the PTLs for the health check for stein? Does anyone have anything to raise based on what they have learned in their conversations? -- Doug

1 1

[glance] (Silly) question about container_format and disk_format
by Andre Florath 03 Jan '19

03 Jan '19

Hello! I do not completely understand the parameters 'container_format' and 'disk_format' as described in [1]. The documentation always uses 'the format' but IMHO there might be two formats involved. Are those formats either (A) the formats of the image file that is passed in. Like (from the official documentation [2]) $ openstack image create --disk-format qcow2 --container-format bare \ --public --file ./centos63.qcow2 centos63-image qcow2 / bare are the formats of the passed in image. or (B) the formats that are used internally to store the image Like $ openstack image create --disk-format vmdk --container-format ova \ --public --file ./centos63.qcow2 centos63-image vmdk / ova are formats that are used internally in OpenStack glance to store the image. In this case there must be an auto-detection of the image file format that is passed in and an automatic conversion into the new format. Kind regards Andre [1] https://developer.openstack.org/api-ref/image/v2/index.html?expanded=create… [2] https://docs.openstack.org/glance/pike/admin/manage-images.html

2 2

Re: [Infra][Cinder] Request for voting permission from LINBIT LINSTOR CI (linbit_ci@linbit.com) for Cinder projects
by Woojay Poynter 03 Jan '19

03 Jan '19

Hello, I would like to request a voting permission on LINBIT LINSTOR CI for Cinder project. We are looking to satisfy third-party testing requirement for Cinder volume driver for LINSTOR (https://review.openstack.org/#/c/624233/) The CI's test result of the lastest patch is at http://us.linbit.com:8080/CI-LINSTOR/33/456/ While the driver itself is still being tweaked on the remaining two failed tests, I hope I can have the CI portion of the requirement ready w/ this request. The testbeds are jenkins slave running fresh installation of devstack w/ target patch triggered from gerrit with lvmthin storage backend managed by LINSTOR driver for Cinder. LINSTOR is storage provisioner using DRBD for block replication. Some of the test results of the LINBIT LINSTOR CI running on openstack-dev/ci-sandbox are here; https://review.openstack.org/#/c/627599/ https://review.openstack.org/#/c/627596/ https://review.openstack.org/#/c/626625/ Thank you for your time during the holidays. Sincerely, Woojay Poynter -- 541-435-1001 woojay(a)linbit.com LINBIT | Keeping the Digital World Running DRBD – Corosync – Pacemaker DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. On Fri, Dec 28, 2018 at 1:51 PM Woojay Poynter <woojay(a)linbit.com> wrote: > Hello, > > I would like to request a voting permission on LINBIT LINSTOR CI for > Cinder project. We are looking to satisfy third-party testing requirement > for Cinder volume driver for LINSTOR ( > https://review.openstack.org/#/c/624233/) The CI's test result of the > lastest patch is at http://us.linbit.com:8080/CI-LINSTOR/33/456/ > > While the driver itself is still being tweaked on the remaining two failed > tests, I hope I can have the CI portion of the requirement ready w/ this > request. > > The testbeds are jenkins slave running fresh installation of devstack w/ > target patch triggered from gerrit with lvmthin storage backend managed by > LINSTOR driver for Cinder. LINSTOR is storage provisioner using DRBD for > block replication. > > Some of the test results of the LINBIT LINSTOR CI running on > openstack-dev/ci-sandbox are here; > https://review.openstack.org/#/c/627599/ > https://review.openstack.org/#/c/627596/ > https://review.openstack.org/#/c/626625/ > > Thank you for your time during the holidays. > > Sincerely, > > Woojay Poynter > -- > 541-435-1001 > woojay(a)linbit.com > > LINBIT | Keeping the Digital World Running > DRBD – Corosync – Pacemaker > > DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. > -- Woojay Poynter – Software Developer +1 503 573-1262 x211 woojay(a)linbit.com LINBIT | Keeping the Digital World Running DRBD – Corosync – Pacemaker DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.

2 1

[cinder] Is the cinder Active-Active feature OK？
by Jaze Lee 03 Jan '19

03 Jan '19

Hello, In my opinion, all rest api will get to manager of cinder volume. If the manager is using DLM, we can say cinder volume can support active-active. So, can we rewrite the comments and option's help in page https://github.com/openstack/cinder/blob/master/cinder/cmd/volume.py#L78 ? Thanks a lot. -- 谦谦君子

2 2

[neutron] Bug deputy report 17th~23rd Dec 2018
by Paweł Suder 03 Jan '19

03 Jan '19

Hello Neutrons, Following bugs/RFE/issues have been raised during last week. Some of them were already recognized, triaged, checked: >From oldest: https://bugs.launchpad.net/neutron/+bug/1808731 [RFE] Needs to restart metadata proxy with the start/restart of l3/dhcp agent - IMO need to discus how to do that. https://bugs.launchpad.net/neutron/+bug/1808916 Update mailinglist from dev to discuss - it is done. https://bugs.launchpad.net/neutron/+bug/1808917 RetryRequest shouldn't log stack trace by default, or it should be configurable by the exception - confirmed by Sławek ;) https://bugs.launchpad.net/neutron/+bug/1809037 [RFE] Add anti_affinity_group to binding:profile - RFE connected with another RFE from Nova related to NFV and (anti)affinity of resources like PFs. https://bugs.launchpad.net/neutron/+bug/1809080 reload_cfg doesn't work correctly - change in review, I tried to review, but no comments left - new contributor https://bugs.launchpad.net/neutron/+bug/1809134 - TypeError in QoS gateway_ip code in l3-agent logs - review in progress https://bugs.launchpad.net/neutron/+bug/1809238 - [l3] `port_forwarding` cannot be set before l3 `router` in service_plugins - review in progress https://bugs.launchpad.net/neutron/+bug/1809447 - performance regression from mitaka to ocata - not triaged, I am not sure how to handle it - it is a wide thing.. https://bugs.launchpad.net/neutron/+bug/1809497 - bug noticed on gates related to another bug opened last week: https://bugs.launchpad.net/neu tron/+bug/1809134 Wish you a good time this week and for the next year! :) Cheers, Paweł

2 2

[all][ptl][heat][senlin][magnum]New SIG for Autoscaling? plus Session Summary: Autoscaling Integration, improvement, and feedback
by Rico Lin 03 Jan '19

03 Jan '19

Dear all Tl;dr; I gonna use this ML to give a summary of the forum [1] and asking for feedback for the idea of new SIG. We have a plan to create a new SIG for autoscaling which to cover the common library, docs, and tests for cross-project services (Senlin, Heat, Monasca, etc.) and cross-community (OpenStack, Kubernetes, etc). And the goal is not just to have a place to keep those resources that make sure we can guarantee the availability for use cases, also to have a force to keep push the effort to integrate across services or at least make sure we don't go to a point where everyone just do their own service and don't care about any duplication. So if you have any thoughts for the new SIG (good or bad) please share it here. Here I summarize our discussion in the forum session `Autoscaling Integration, improvement, and feedback`. If you like to learn more or input your thoughts, feel free to put it in etherpad [1] or simply reply to this email. In the forum, we have been discussed the scope and possibility to integrate effort from Heat, Senlin, and also autoscaling across OpenStack to K8s. There are some long-term goals that we can start on like create a document for general Autoscaling on OpenStack, Common library for cross-project usage, or create real scenario cases to test on our CI. And the most important part is how can we help users and satisfied use cases without confuse them or making too much duplication effort across communities/projects. So here's an action we agree on, is to trigger discussion for either we need to create a new SIG for autoscaling. We need to define the scope and the goal for this new SIG before we go ahead and create one. The new SIG will cover the common library, docs, and tests for cross-project services (Senlin, Heat, Monasca, etc.) and cross-community (OpenStack, Kubernetes, etc). And the goal is not just to have a place to keep those resources that make sure we can guarantee the availability for use cases, also to have a force to keep push the effort to integrate across services or at least make sure we don't go to a point where everyone just do their own service and don't care about any duplication. For example, we can have a document about do autoscaling in OpenStack, but we need a place to put it and keep maintain it. And we can even have a place to set up CI to test all scenario for autoscaling. I think it's possible to extend the definition of this SIG, but we have to clear our goal and make sure we actually doing a good thing and make everyone's life easier. On the other hand we also need to make sure we do not duplicate the effort of other SIGs/WGs. Also The reason I add `ptl` tag for this ML is that this SIG or the concept of `autoscaling` might be very deferent to different projects. So I really wish to hear from anyone and any projects who are interested in this topic. [1] https://etherpad.openstack.org/p/autoscaling-integration-and-feedback -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

4 3

[nova] Granular locks in the API
by Matt Riedemann 03 Jan '19

03 Jan '19

I wanted to float something that we talked about in the public cloud SIG meeting today [1] which is the concept of making the lock API more granular to lock on a list of actions rather than globally locking all actions that can be performed on a server. The primary use case we discussed was around a pre-paid pricing model for servers. A user can pre-pay resources at a discount if let's say they are going to use them for a month at a fixed rate. However, once they do, they can't resize those servers without going through some kind of approval (billing) process to resize up. With this, the provider could lock the user from performing the resize action on the server but the user could do other things like stop/start/reboot/snapshot/etc. The pricing model sounds similar to pre-emptible instances for getting a discount but the scenario is different in that these servers couldn't be pre-empted (they are definitely more non-cloudy pets than cattle). An alternative solution for that locked resize issue is using granular policy rules such that pre-paid servers have some other kind of role attached to them so by policy you could restrict users from performing actions on those servers (but the admin could override). In reality I'm not sure how feasible that is in a public cloud with several thousand projects. The issue I see with policy controlling this is the role is attached to the project, not the resource (the server), so if you did this would users have to have separate projects for on-demand vs pre-paid resources? I believe that's what CERN and StackHPC are doing with pre-emptible instances (you have different projects with different quota models for pre-emptible resources). I believe there are probably other use cases for granular locks on servers for things like service VMs (trove creates some service VMs to run a database cluster and puts locks on those servers). Again, definitely a pet scenario but it's one I've heard before. Would people be generally in favor of this or opposed, or just meh? [1] https://etherpad.openstack.org/p/publiccloud-wg -- Thanks, Matt

4 5